Newsgroup: it.lavoro.informatica
Titolo: Specifiche UML (non è come pensate...)

Ciao a tutti,
stavo leggendo questo articolo: 
http://littletutorials.com/2008/05/15/13-reasons-for-umls-descent-into-darkness/
 
intitolato "13 reasons for UML’s descent into darkness". Al di la 
dell'essere d'accordo o meno, vorrei segnalarvi il putno 3:
"3. Tries to unify everything even the kitchen sink (UML specs > 800 pages)"
Io ho una mezza specie di specifica UML. E la tengo sempre sulla mia 
scrivania.
La uso per tenere il monitor sollevato[1]! :-D
Ciao,
Giulio
[1] Non è uno scherzo, nè un modo di dire. Documentone di corso sull'UML 
- mai usato - e tre elenchi telefonici...
-- 
OnAir: The Darkness - "Love is Only a Feeling"
http://www.giuliopetrucci.it
http://www.fujikomonamour.com

 - mai usato - e tre elenchi telefonici...
Io uso un faldone per un monitor (non so cosa c'e' dentro, l'ho
ricevuto in eredita' dal precedente locatario del desk) ed una risma
Xerox di 500 pagine A4 80 g/m2 per l'altro.
--
ale
http://ale.riolo.co.uk

 "3. Tries to unify everything even the kitchen sink (UML specs > 800 pages)"
Sono parzialmente daccordo con l'articolo. UML offre soluzioni per il
software  e di certo non raccoglie tutti gli aspetti implementativi di un
software. Si parla di astrazione e non di  codice, altrimenti siamo punto
e capo. I class-diagram , imho, non sono l'unico strumento valido di UML,
direi che gli use-case sono molti utili per suddividere il sistema in
componenti, gli state-chart li ho usati spesso per software embedded, per
modellare il comportamento di fronte ad eventi esterni. La notazione
grafica non vuol dire mancanza di chiarezza, questo avviene perchè
l'analista non si studia la semantica di un modello. UML non è un
accozzaglia di simboli, ma è definito da una semantica (Meta-modello).
Detto questo, capisco che per chi ha a che fare, ogni giorno, con i
medesimi problemi non si accorge neanche dello sforzo progettuale già a
sua disposizione. Chi sviluppa applicazioni Web utilizza almeno 3 modelli
architetturali ben documentati e funzionanti: 
1) Modello stratificato (Stack ISO/OSI oppure framework quali Java o .NET)
2) Modello Client/Server
3) Modello relazionale
In sistemi concorrenti è difficile iniziare a scrivere codice funzionante,
senza avere una visione globale del problema. Questo causa problemi e bug
non scopribili con simulazioni o testing, ma con un'analisi degli stati
fatta appunto sul modello e non sul codice.
My 2 cent.
 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 - mai usato - e tre elenchi telefonici...
UML è uno strumento e un linguaggio, come viene utilizzato è un altro 
discorso. Se usato impropriamente può portare ai problemi elencati 
nell'articolo, ma conosco progetti, anche di grosse dimensioni, dove UML 
è stata una delle chiavi di successo del progetto.
ciao, U.

 Xerox di 500 pagine A4 80 g/m2 per l'altro.
Ma non avete il monitor un po' troppo alto ?
Io ogni tanto mi devo recuperare altrimenti scivolo lentamente sotto
la scrivania...
Shift

 scrivania.
Il guaio di UML, probabilmente, è di essere troppo ambizioso, e quindi
prolisso, rispetto ai risultati concreti ottenibili. Cioè progettare
in UML non ti garantisce automaticamente un valore aggiunto, rispetto
al non usarlo. Questo è un handicap pesante, visto lo sforzo di
imparare il suo standard sterminato.
Tra l'altro, come tutti i linguaggi grafici, è intrinsecamente molto
poco pratico nel descrivere minuziosamente (cioè fino al livello degli
algoritmi dei metodi) un sistema complesso. Non è che mancano i
simbolismi, ma realizzare diagrammi di ogni singolo pezzetto del
sistema è un lavoro improbo.
Ed alla fine, nel software, quello che conta è l'implementazione e la
sua descrizione dettagliata.

 sua descrizione dettagliata.
Dipende.
Il codice è importante perché fa le cose.
Una descrizione piu' astratta del software è utile per manutenerlo il 
software.

 dell'essere d'accordo o meno, vorrei segnalarvi il putno 3:
Dico la mia sull'articolo punto per punto:
1. Design by committee
Mi sembra che sia andata così:
UML è stato per gran parte creato da tre persone che hanno amalgamato 
tre metodologie creando il RUP.
Poi UML è stato stadardizzato da qualche comitato.
L'autore pensa che sia un problema perché ad esempio CORBA che è stato 
progettato da un comitato non lo soddisfa. Non ho capito perché.
2. The obsessive focus on monetizing UML
Esistono tool UML opensource.
3. Tries to unify everything even the kitchen sink (UML specs > 800 pages)
UML è vasto, che problema c'e'. Non devi conoscerlo tutto per usarlo.
4. Departure from what programmers perceived as the initial goal
Cito:
 > UML started to go up into the stratosphere with all those business 
oriented diagrams that even the business people didn’t understand or use.
Nessuno ti obbliga usare i diagrammi che non vuoi.
UML è come un supermercato, vai e prendi solo le cose che ti interessano.
Il progettista prima di tutto capisce quali diagrammi servono per 
documentare il software, poi li crea.
E' matto chi pensa che deve usare sempre tutti i diagrammi UML.
5. Concept bloat
UML non deve essere usato descrivere tutti i concetti possibili e 
immaginabili. Se l'autore ha bisogno un linguaggio che descriva tutti 
aspetti del Java come le inner classes che usi il Java.
6. Always catch-up with new languages and concepts
Ritorniamo al punto di prima. UML non puo' rappresentare tutti i 
costrutti di qualsiasi linguaggio.
UML è utile per astrarre concetti, non per descriverli tutti.
7. UML attempts to become a programming language
L'autore ha ragione sul dire che le immagini sono migliore per 
presentare concetti in astratto e le parole in dettaglio.
L'UML non essendo un essere senziente non vuole diventare nessuno.
8. The need for expensive tools vs. just a text editor
 > Tools that are any good are insanely expensive.
http://www.staruml.com/
 - StarUML
Tool opensource.
Cosa ci fai con un text editor? Descrivi il software ma senza diagrammi. 
  A mio parere la visione di insieme si riesce a dare meglio con le 
immagini.
L'UML non è la prima notazione grafica usata per documentare il 
software. Quest'idea c'e' sempre stata ed è sempre stata utilizzata.
Prima di UML c'erano i DataFlowDiagram, i diagrammi ERA e gli state 
diagram.
10. Lack of solutions for real software design issues
I problemi di design si risolvono con metodologie di progettazione.
Se l'autore vuole dire che non si riesce a rappresentare certe cose con 
i modelli UML va bene.
Comunque in UML si posso descrivere le dipendenze tra i casi d'uso.
11. Assumes you can know everything before writing the first line of code
La manuntezione dei diagrammi UML la fai se serve.
Quando fai micro design il diagramma puoi farlo su un pezzo di carta e 
poi buttarlo come nella migliore tradizione dell'extreme programming.
Quando devi documentare l'architettura di un sistema forse è meglio 
mantenere qualche diagramma.
Basta non cercare di mantenere mille diagrammi per un software solo.
E poi il microdesign cambia spesso, il design generale no.
12. Treat software development like manufacturing
 > UML tries to standardize and formalize the unknown, the imagination 
and the talent.
Cazzate.
UML è un modello, non un processo di sviluppo.
Questo parla di UML senza sapere cos'è. Va bene parlare dei difetti 
degli strumenti che usiamo perché tutti gli strumenti hanno difetti e 
molto meglio conoscerli che pensare che lo strumento che usi sia il 
migliore in assoluto. Ma questo non sa neanche di cosa sta parlando.
13. UML tools focus on the wrong goal
 > Most of the UML tools out there promise code generation.
Io non so come gliel'hanno venduto UML a lui, ma sono d'accordo che la 
generazione del codice a partire dal diagramma non sia sempre utile.
Mi sono stufato le ultime righe non le leggo.

 codice userei proprio il codice.
Su questo concordo in pieno ma, come dice giustamente ispas, UML 
pretende di farlo (ed è per questo che è sostanzialmente fallito).
Salute.

 il software.
Giusto. Ma personalmente non mi sembra che UML sia di per sè uno
strumento più chiaro e con meno ambiguità di una buona documentazione
testuale. Anche perchè in UML c'è ampio spazio per testo descrittivo
ed esplicativo (note, condizioni, ecc.).
Perciò è uno strumento utile, può completare una documentazione. Ma
non mi sembra che possa essere "il" linguaggio di
progettazione/documentazione, come ambiva ad essere.

 pretende di farlo (ed è per questo che è sostanzialmente fallito).
UML non pretende niente, è uno standard non è una persona.

 progettazione/documentazione, come ambiva ad essere.
D'accordo sul fatto che non deve essere IL linguaggio per la 
documentazione ma uno dei modelli da usare per documentare.
Quando documento l'architettura di un software sono molte, ma molte di 
più le parole del testo che gli elementi grafici dei diagrammi.
Ma chi ha messo in giro questa stupidata che tutta la documentazione 
dovrebbe essere scritta in UML? Anche se l'avesse detto il signor UML 
per me è una stupidata.
Ciao

 Ma le ambizioni dell'UML erano tutt'altre.
Spiegatemi questa cosa. Intendete che qualcuno pensava che si potesse 
arrivare a programmare in UML?

 
E proprio così.
Non viene usato. Da nessuno.
Anche quelli che lo usano fanno finta.
Lo fanno solo convincere gli altri che serve.
Ciao

 arrivare a programmare in UML?
Esistono dei profili UML detti: "Executable UML", pienamente eseguibili.
In pratica, si prende un diagramma delle classi e si associa ad ogni
classe una  
macchina a stati finiti. Ora con un compilatore di modello si tira fuori
un action language, che puň avere la stessa sintassi di Java o C# o
un'altro framework OO, quindi pienamente compilabile, oppure č possibile
usare linguaggio intermedi come Object-Oriented-XML, che si trasformano
facilmente in linguaggio. 
Il problema č: si fa prima a scrivere il codice direttamente partendo dal
diagramma delle classi o a definire una macchina a stati finiti per ogni
classe ?? 
Vorrei spezzare una lancia a favore di UML. UML č, come l'informatica,
giovane
e per questo ancora un po inconsistente, ma diamo tempo al tempo. 


 classe ?? 
E aggiungerei anche: č piů facile manutenere e/o debuggare il codice o 
il diagramma UML?


 
Bè, si potrebbe pensare questo da 2 fatti: proprio la ricchezza delle
specifiche UML, che quindi vuole coprire tutto lo scibile informatico;
e la spinta che hanno avuto (hanno ancora?) certi tools costosissimi,
come quelli Rational.


Per quanto riguarda i prodotti Rational ti posso dire questo, che mi 
sembra vero che cerchino di coprire tutte le problematiche del processo 
di sviluppo, pero' non tutti sono tool UML.
RequisitePro di Rational (ormai IBM) che si usa per gestire i requisiti 
e che costa un sacco e non è un tool UML.

 
Sono d'accordo. Strumenti/linguaggi come UML, che non sono proprio
immediati, *devono* dare qualche valore aggiunto. Questo non sta
sicuramente nella maggiore velocità di realizzazione delle
applicazioni. Sta allora nella rigorosità formale, che fa aumentare
molto la correttezza dell'applicazione? Dubito fortemente.


Anch'io.
Secondo me per garantire la correttezza di un software è molto meglio 
utilizzare le revisioni tecniche dei pari e un piano di testing ben pensato.
-- 
Andrea Francia
http://code.google.com/p/remoted-list/
 - Lazy loading lists through RMI.

 come quelli Rational.
questa è una tua interpretazione molto personale.
dei modelli uml si utilizzano solo quelli che sono utili nel processo di 
sviluppo e solo quando lo sono. su questo i testi sono molto chiari. se 
mi puoi citare una metodologia che impone i formalismi uml come stai 
insinuando te ne sarei grato.
nel frattempo, visto che hai citato rational, ti suggerirei "uml e 
unified process" (arlow, neustadt - isbn 88-386-6144-8) anche solo per 
la prefazione.
-- 
 Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/

 come stai insinuando te ne sarei grato. 
Allora qualcuno dovrebbe spiegare razionalmente perchè UML prevede n
tipi di diagrammi diversi, salvo poi dire: però usate solo quelli che
vi servono. I quali, nel 99% dei casi, sono i soliti 3 o 4.
Per quanto riguarda RUP, basti dire che ti vendono, a prezzi
salatissimi, tools monolitici che creano *tutti* i vari tipi di
diagrammi e modelli. Evidentemente c'è a chi piace usare il 20% di
quello che paga.

 quello che paga.
io so che una decina di anni fa rational rose era il tool unico nel suo 
genere. oggi nel mondo opensource ce n'è da benedire e santificare, 
oltre al fatto che ogni ide di sviluppo che si rispetti ha il suo 
designer uml.
se qualcuno paga salatissimo avrà le sue buone ragioni, ma bisognerà che 
tu le chieda a lui e non a me.


 arrivare a programmare in UML?
Lo so, è terribile, ma devi fartene una ragione.

 UML non pretende niente, è uno standard non è una persona.
E poi ci si meraviglia che abbia vinto testa d'asfalto.

 perchè, non riesci a darti da solo una spiegazione razionale?
x ispas:
Ci vuole tanto ad arrivare a pensare che se a te servono alcuni 
diagrammi ad altri potrebbero servire diversi diagrammi?


 diagrammi ad altri potrebbero servire diversi diagrammi?
Mi sembra che ribalti la questione. Io sto dicendo che UML aveva/ha
l'ambizione di essere lo strumento o linguaggio di elezione dell'IT, e
che questo è dimostrato dal suo prolifico armamentario di diagrammi,
notazioni, estensioni, labels, tags, ecc. Tutto qua.
Nessuno dei creatori di UML lo propone come unico linguaggio/strumento?
Io non ho per niente questa impressione. Ma se anche fosse, meglio
così, tanto non ci sono riusciti :-)


Ecco una risposta che nonostante non voglia dire niente viene detta come 
se fosse una osservazione sagace....
Che c'entra?



Adesso ho capito cosa intendi.
Sul fatto delle intenzioni la pensiamo diversamente ma fa niente.
Tanto per me non è un'argomento così interessante da discuterne.
In ogni caso, come dici tu, non ci sono riusciti, e, dico io, non 
sarebbe servito.


 - mai usato - e tre elenchi telefonici...
Non voglio entrare nel merito della discussione perche' per me ci sarebbe
troppo da discutere ma vorrei focalizzare su un punto. E' semplice
criticare ma una critica del genere non porta a nulla se non si vengono
esposte le alternative. Cosa si fa? Si fa un'analisi ognuno a proprio modo
e poi se uno lascia l'azienda bisogna ricontattarlo per farsi spiegare che
cosa significano i geroglifici che ha riportato su un documento? Oppure
non si fa analisi per nulla? Si ritorna ai CASE tools? Per molti che si
sono affacciati all'informatica dopo gli anni 90 hanno cominciato solo con
UML visto che era l'alternativa migliore all'epoca soprattutto per
linguaggi OO. Ora se ne incominciano a vedere alcuni limiti e soprattutto
alcuni allargamenti dello scopo iniziale che spesso hanno portato piu'
confusione che benefici. La domanda pero' rimane: a che serve trovare i
lati negativi senza portare alternative? Per farti un esempio, ti potrei
trovare 20 lati negativi nell'usare un automobile. Pero' se devi farti
20km per andare al lavoro e non ci sono mezzi pubblici rimane comunque
l'alternativa migliore piuttosto che andarci in bicicletta o a piedi. Che
poi la usi sgommando o a marcia indietro non significa che sia
l'automobile che e' sbagliata. Significa probabilmente che non hai letto
il manuale di istruzioni dell'automobile proprio come tu non hai fatto con
quel manuale del tuo corso. Di persone che vanno a lavorare in macchina
cosi' come di progetti analizzati in UML ce ne sono a milioni. Poi se tu o
l'autore dell'articolo riesce ad inventarsi un mezzo migliore di trasporto
(che so inventando un veicolo non inquinante e che non si rompe mai) o un
modo migliore per realizzare l'analisi che ben vengano ma se si tratta
solo di scoprirne le imperfezioni l'utilita' di questi discorsi si perde
subito.


 Ecco una risposta che nonostante non voglia dire
Una risposta non può "volere" niente, è una risposta non è una persona :P


Questa risposta invece *è* sagace. Mi hai fregato :)
Per ritornare al discorso di UML, volevo dire: un conto è dire per 
esempio che i promotori dello standard UML, la (ex) Rational, o chiunque 
altro pretende qualcosa, dire che UML pretende qualcosa non vuol dire 
niente.


 lati negativi senza portare alternative?
Non ci sono alternative a UML non nel senso che c'e` solo lui ma nel
senso che non serve a nulla.
Poi ognuno faccia quello che vuole, se si trova bene con uml meglio per
lui, io e tutti quelli con cui lavoro e che conosco non si trovano bene
con uml e semplicemente non lo usano. Pura e semplice perdita di tempo.
-- 
Valentino Volonghi aka Dialtone
http://stacktrace.it
 -- Aperiodico di resistenza informatica
Blog: 
http://www.twisted.it/
Public Beta: 
http://www.adroll.com/

 
E la logica che fine a fatto?
Il fatto che alla gente che conosci tu non serva UML non implica che non 
serva a nessuno. A meno che tu non conosca tutti gli abitanti del mondo.
Io non uso, e nessuno tra le persone che conosco usa, l'acido hialuronico.
Ma da qua a dire che non serve a nulla ce ne passa.


 con uml e semplicemente non lo usano. Pura e semplice perdita di tempo.
Dubito che almeno uno use-case, un diagramma di classi o un sequence o
activity diagram nessuno lo faccia. Magari lo fa a modo suo, senza seguire
alcuna convenzione (e a questo punto sarebbe meglio seguire uno standard
in modo che anche gli altri riescano a leggerlo) ma non riesco a credere
che un programmatore oggi posso mettersi a scrivere codice senza nessuna
attivita' di analisi, a meno che ovviamente non sia il solo ad occuparsi
dell'attivita' e per cui tutte queste cose le fa nella sua testa. Poi
ripeto, se ci sono alternative migliori sono il primo a volerle ascoltare.


 che ha riportato su un documento? Oppure non si fa analisi per nulla?
Quello che dici è molto giusto. Purtroppo non mi sembra che UML da solo
abbia quella chiarezza, e sia così privo di ambiguità, da poter avere
quella preminenza che ha cercato di ottenere tra i linguaggi/strumenti
di analisi.
I "geroglifici" ce li dovremo tenere ancora per un bel pezzo :-)

 cosa significano i geroglifici che ha riportato su un documento? 
Prova a leggere un documento di specifiche che scrivo io e poi dimmi
se c'e' bisogno di ricontattarmi (putroppo non ce n'e' bisogno, altrimenti
mi avrebbero pagato molto di piu', come pagano di piu' tutti quelli che
scrivono geroglifici)
Ciao,
Marco


 scrivono geroglifici)
Credo che il punto fosse questo: perché uno deve reinventarsi un modo 
per fare i diagrammi quando esiste già un modo standardizzato che quasi 
tutti conoscono?
Certo che uno può sempre scrivere un documento incomprensibile usando 
anche il più standard dei linguaggi di modellazione oppure scrivere un 
documento comprensibile usando un linguaggio inventato.


 scrivono geroglifici)
Se dipendesse da me, uno che non è capace di documentare il software lo 
chiamerei per un progetto e poi non lo chiamerei piu'.


 ripeto, se ci sono alternative migliori sono il primo a volerle ascoltare.
CRC cards?
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
 - 
stacktrace.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 documento comprensibile usando un linguaggio inventato.
O scrivere un documento chiaro con degli esempi in lingua italiana (o al
limite in inglese)


 activity diagram nessuno lo faccia. Magari lo fa a modo suo, senza seguire
Mai scritto un diagramma delle classi in tutta la mia vita, men che meno
il sequence. Di activity ne ho scritti una 40ina in universita` a suo
tempo per un corso che non aveva nulla a che fare con la programmazione.
Ci sono fior di progetti enormi nel mondo che non hanno bisogno di
diagrammi o perdite di tempo simili e funzionano molto meglio dei
software farciti di diagrammi in ogni posto.
Il punto e` che rispetto a 20 anni fa UML e` meno usato nel software e
piu` usato in posti completamente irrilevanti per l'uml semplicemente
perche` non e` un prodotto utile allo sviluppo del software ma alla
descrizione, molto schizzata e imprecisa, di sistemi. Risultato e` che
lo studiano nelle universita` i gestionali per descrivere i processi
aziendali (e anche li` non e` che sia poi sta grande utilita`).


 Ma da qua a dire che non serve a nulla ce ne passa.
Battuta carina ma fuori luogo perche` svicola dal merito cercando di
portarsi su un piano totalmente diverso. Se il chirurgo plastico non usa
l'acido hialuronico o non offre un servizio o lo offre attraverso altri
espedienti senza per forza avere un sostituto dell'acido.
Tuttavia io scrivo software e senza usare un sostituto dell'acido quindi
significa che esiste un mondo al di la` della barricata.


 
Il linguaggio naturale hai suoi limiti. Non si può usare solo quello.


 scrivania.
Per me l'UML e' una delle pochissime cose utili partorite dall'OMG, ma
infatti la critica dell'articolo mi pare piu' una critica
sull'approccio model driven che non all'UML di per se, e su questo
sono al 100% d'accordo.
Comunque, l'UML consente di esprimere in modo sintetico cose piuttosto
complesse, ma occorre conoscere bene la specifica, e quasi nessuno la
conosce bene (me incluso). In ogni caso e' un linguaggio, niente di
piu'.

 uml
Da quando in qua Fowler è uno degli autori di UML?
Mai sentito parlare di Three Amigos?
Adesso viene fuori che Fowler è il quarto?


 Adesso viene fuori che Fowler č il quarto?
Pardon hai ragione, non e` uno degli autori. Torniamo al discorso quindi
su quello glissi invece?


 Il linguaggio naturale hai suoi limiti. Non si può usare solo quello.
Infatti io ho usato la parola esempi. Che possono essere schemi, codice,
diagrammi. Quel che ti pare. Ma usare tutto UML è overengineering.
Semmai si salvano i diagrammi di classe.


 software farciti di diagrammi in ogni posto.
Il fatto che sia una perdita di tempo è una tua (discutibile) opinione 
personale.


 significa che esiste un mondo al di la` della barricata.
Ho mai detto che tutti devono usare UML?
Quello che non capisci e che ci sono progetti per cui UML va bene e 
progetti per cui è un male.
Se nella tua esperienza hai incontrato solo progetti dove usare UML era 
inutile o anzi dannoso non vuol dire che sia inutile in generale.
Ma ho paura che tu capisca solo gli schieramenti estremisti. Dato che ho 
detto che non è vero che non serve a nulla allora per te vuol dire che 
secondo me serve sempre. Beati fondamentalisti.


 
Non avevo voglia di leggere.
I post troppo lunghi annoiano. Perdonami.
Se ti fa piacere puoi pensare che quando non rispondo sono d'accordo con te.


 
Se non specifichi cosa intendi con esempi non si può capire.
Ho detto che bisogna usare UML per tutto?
Le specifiche che faccio io contengono testo, tabelle, esempi, e diagrammi.
Quando i diagrammi possono essere descritti con UML uso UML.
Se non esiste una notazione UML per i diagrammi cerco comunque di usare 
un standard abbastanza conosciuto. Come le notazioni piu' conosciute per 
i Data Flow Diagram o dei Entity Relationship Attribute Diagram.


 personale.
No, e` una perdita di tempo, e` il contrario che e` una tua opinione
personale, se per il tuo modo di ragionare ti e` utile uml ben per te,
il modo di ragionare efficace non ha bisogno di uml e ne trae solo
perdite.


 Se ti fa piacere puoi pensare che quando non rispondo sono d'accordo con te.
Bah, sei un coglione allora. E prendilo come un'offesa se vuoi. Resta
nel tuo brodo.


 i Data Flow Diagram o dei Entity Relationship Attribute Diagram.
Ottimo :)


 
:-D
Te la sei presa?
Consiglio: Evita di usare parole offensive, ci fai più bella figura.
Per tua informazione non puoi costringere la gente a leggere tutto 
quello che scrivi. Man mano che il post diventa lungo la probabilità che 
tutti lo leggono diminuisce. Ma sicuramente qualcuno l'ha letto tutto.


 perdite.
Certo anche la mia è un opinione.
La tua invece è una Verità.
Ci sono due tipi di Verità: gli atti di fede, e le verità dimostrate 
scientificamente.
Puoi dimostrare scientificamente la tua affermazione?
Oppure mi puoi dire a che religione mi devo iscrivere per crederci?


 Resta nel tuo brodo.
Se pensi che ci sia qualcosa meglio di UML e vuoi convincere qualcuno 
sbagli approccio.
Dire "UML non serve a niente, punto!" non convincerà mai nessuno che non 
sia dipedente psicologicamente da te, cioé nessuno in questo newsgroup 
frequentato da lettori con una discreta intelligenza.
Se vuoi convicere qualcuno potresti dire "Quando fai progetti del tipo 
.... usare UML è un pacco perché ..., molto meglio usare ... perché ...".
Oppure "Quando ho fatto ... al posto di usare UML ho usato ... e mi sono 
trovato bene perché ... ".
Questi sono modi di porsi che portano a discussioni produttive dove alla 
fine l'opinione di qualcuno cambia e in genere si perfeziona.


 ripeto, se ci sono alternative migliori sono il primo a volerle ascoltare.
Ma di alternative ce ne sono finché ne vuoi!
Quello dell'ingegneria del software è uno dei temi più dibattuti 
dall'umanità, sul quale ognuno s'è sentito in diritto di dire qualcosa.
Parti ad esempio da qui:
http://c2.com/cgi/wiki?LocalityOfReferenceDocumentation
e poi zompetta di link in link.
Ne avrai per settimane (e alla fine, forse, sarai illuminato).
(Per il resto, grosse cazzate non ne hai dette.)

 sbagli approccio.
Sommario per i poco dotati cerebralmente: difficile insegnare a chi non
ha neanche la testa per leggere ma ha il coraggio di rispondere
ugualmente.
Contenuto integrale per i normodotati:
Guarda, io non guadagno un dollaro in piu` per convincerti e non sono
pagato da nessuno per farlo, questo significa che non mi puo` fregare di
meno quello che fai tu o chiunque altro. Se voglio dire che UML non
serve a nulla lo dico, ho riportato estratti da post di persona che
quelli come te potrebbero considerare piu` autorevoli e il mio 'lavoro'
l'ho fatto.
Poi fatti tuoi o di chi altro, siccome ti sei persino dimostrato un
pessimo interlocutore oltre che pseudo maestro di vita non ho piu`
interesse e, ripeto, ti lascio nel tuo brodo.


 Lo so, è terribile, ma devi fartene una ragione.
 >
Citazioni, please. Io sono interessato, puntami su qualche progetto 
riuscito.
Ciao,
     Bruno
P.S.
Occhio ai meeting del JUG Torino!
http://www.jugtorino.it/meeting
-- 
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://www.jugtorino.it/bbossola
| Coordinatore del JUG Torino - 
http://www.jugtorino.it


Io personalmente trovo UML un potentissimo mezzo per comunicare 
all'interno di un team. Spesso, in progetti "veri" (non parliamo di 
webapp crud) confrontandosi sulla logica di business si sente la 
necessità di descriverne il funzionamento ad un livello di astrazione 
più alto: ecco che un diagramma UML permette di catturare l'essenza del 
design senza scendere in microscopici dettagli che sul codice saresti 
costretto ad ignorare consapevolmente.
Ad esempio, suppongo che tu abbia letto il GOF: i diagrammi OMT della 
prima edizione aiutano parecchio a capire il pattern, e se fossero 
supportati da un diagramma di collaborazione li renderebbero ancora più 
semplici.
L'uso più comune che io faccio di UML é comunque non legato ad una 
documentazione monolitica, come quella consigliata da RUP, per esempio, 
ma come mezzo per comunicare all'interno del team. Uno schizzo in UML è 
molto più rapido che uno schizzo in $linguaggio.
My 2 cents,


 l'ho fatto.
Nell'articolo che hai riportato non c'e' scritto che UML non serve a 
nulla. Questa è una tua particolarissima interpretazione.


 riuscito.
Citazioni di cosa? Di nuovo, sei sicuro di aver capito di cosa si parlasse?

 Hai capito di cosa si parlava? (Domanda retorica).
Provo ad interpretare, ma a dire il vero faccio fatica anch'io a seguire
il discorso.
Uno di voi parlava di Executable UML e l'altro di generazione delle stub 
delle classi dal diagramma UML.


 
Si, evidentemente non sono stato chiaro. Quando io penso a "programmare 
in UML", come diceva Cammello, penso ad MDA e a xUML, non certo ad uno 
strumento per fare rountrip diagramma / codice. Per questo ho spostato 
il fuoco su quell'argomento che, fra l'altro, mi interessa molto. Sono 
abbastanza certo che rappresenti il futuro, ma non è certo prossimo, 
almeno a giudicare dai tool a disposizione (commerciali e no)


 almeno a giudicare dai tool a disposizione (commerciali e no)
Mi avevano detto che la Rational faceva prodotti Executable UML per i 
sistemi real time. Non so piu' che questo.


 stato di fatto, sarei interessato a leggerli.
Ti sembra male, molto male.
Un saluto.

 
Ok,allora torniamo in topic. Tu hai effettivamente usato uno dei tool 
che citi? Io l'ho fatto (ho usato sia AndroMDA che Taylor) e devo dire 
che è possibile, usando MDA e xUML, arrivare ad un risultato 
interessante. Purtroppo ho dovuto mollare tutto un po' di tempo fa, ma 
con Taylor, ad esempio, che è una sorta di super-plugin MDA per Eclipse, 
sono andato ben oltre ad un semplice scheletro dell'applicazione (quello 
ti viene fornito in pratica dal PSM). Il grosso problema, nel mio caso, 
è la scarsa e incompleta conoscenza che ho di xUML (e anche del tool), 
oltre che a un'immaturità generale degli strumenti (e includo anche le 
versioni commerciali degli strumenti di IBM/Rational)
Per quanto riguarda le perplessità del mondo degli sviluppatori, beh, io 
mi ricordo di persone che non volevano usare un compilatore perché 
ritenevano impossibile realizzare certe cose senza l'assembler, e quindi 
per loro chiunque usava un linguaggio di alto livello era un visionario. 
Persone che non ritenevano adeguato strutturare il software a layer, e 
che rifiutavano quindi di realizzare strutture complesse usando strati e 
che pretendavano che l'unico modo per farle funzionare fosse scrivere 
tutto insieme, senza "effetto cipolla" (cosi lo chiamavano). O persone 
che ritenevano che la command line interface fosse del tutto 
insostituibile, e che i sistemi operativi a finestre fossero solo dei 
simpatici giochini. O gente che pensava che Internet fosse solo uno hype 
(beh, questo credo ce lo ricordiamo tutti, Zio Bill ha fatto scuola :D)
Secondo me MDA ha un futuro, non a breve termine, ma già ora puo' essere 
usata (anche se in modo parziale) per realizzare una parte delle 
funzionalità di qualche applicazione, per poi integrarle con codice 
scritto da sviluppatori reali. (MDA è forward-only e si presta a questo 
approccio "artigianale"). Penso che in futuro l'approccio sarà sempre di 
più questo, con l'essere umano dedicato a realizzare il domain model e a 
scrivere quella parte di logica di business difficilmente esprimibile 
formalmente, perché originata dal pensiero umano, mentre gli strumenti 
ci generano tutto il codice "boilerplate". Se pensi ad alcune soluzioni 
che magari usi abitualmente (gli ORM per l'accesso al DB, le annotazioni 
in generale, l'instrumentazione che ti fornisce Spring, l'uso di AOP, i 
tool per i webservices) siamo già in queste condizioni, solo che la 
parte umana è ancora preponderante. A mio parere è certamente possibile, 
in futuro, che si faccia a meno quasi ovunque di un linguaggio di alto 
livello (come Java o C#) come a suo tempo si è fatto a meno 
dell'assembler in favore di questi ultimi. Sostituendoli con MDA e xUML? 
Maybe, secondo me sono dei buoni candidati, ancora troppo giovani. Mi 
piacciono? No, direi di no, preferisco un sano linguaggio OO, ma non per 
questo posso liquidarli dicendo che sono uno hype.


 livello era un visionario. 
Tocchi un punto importante. Oggi come oggi nessun programmatore "sano
di mente" si metterebbe a modificare, o solamente a leggere, il codice
assembler prodotto dal compilatore (ovviamente parlo in generale, ci
sono casi dove si fa, ma non sono certo quelli delle applicazioni
desktop, dei sistemi aziendali, ecc.).
Penso quindi che quando i tools MDA o simili saranno in grado di
passare direttamente dal modello al codice macchina, allora avranno
pieno successo. Invece finchè generano codice intermedio in Java od
altro ci sarà sempre qualcuno che ci metterà le mani direttamente,
"tagliando il cordone ombelicale" tra modello e codice, e così
rendendo il modello non più allineato.

 versioni commerciali degli strumenti di IBM/Rational)
Curiosità: se non hai mai usato Argo, perché ne parli così male?

Si tratta di un argomento molto interessante, che però non posso 
approfondire per assoluta mancanza di tempo.
Permettimi quindi qualche commento sbrigativo su quelle che ritengo 
delle semplificazioni forse eccessive da parte tua.
In generale le tue sono considerazioni senz'altro ragionevoli.
Tuttavia l'esempio dell'assembly non mi sembra dei più calzanti. 
Passando da assembly a un linguaggio application oriented (comunque 
*imperativo*) come Java o C#, il salto non è eccessivo: si rimane 
ugualmente in un dominio /testuale imperativo/.
Posso programmare in un linguaggio come il C senza perdere nulla o quasi 
della potenza dell'assembly, e quando mi serve proprio l'assembly, posso 
scriverlo inline al mio codice C, ad ulteriore riprova del fatto che i 
due domini sono largamente sovrapponibili.
Viceversa con UML passo da un dominio testuale ad un dominio visuale, 
per giunta prevalentemente dichiarativo (l'aspetto imperativo è 
confinato essenzialmente agli activity diagram, che per giunta si 
sposano malissimo con il codice strutturato).
Il salto è clamoroso. Visto che hai parlato di ORM, sicuramente avrai 
presenti le difficoltà di mapping tra i due ambienti note come 
"object-relational impedance mismatch":
http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
Orbene, nel caso di UML avremmo addirittura due diversi mismatch, quello 
"visual-textual" e quello "declarative-imperative" (i nomi sono 
ipotetici) ognuno dei quali da solo è dieci volte più problematico di 
quello object-relational sopra citato.
E' un mismatch difficile da sanare, anche in futuro, senza contare che 
nell'immediato hai pure una serie di altri problemi legati all'impiego 
di tool inerentemente testuali in ambito visuale (editor,  debugger etc. 
Come ha già giustamente detto qualcuno in questo thread: ti immagini 
debuggare un diagramma?)
Quindi UML va buttato?
No, in reverse engineering (o comunque per scopi documentali) può 
tornare utile.
Va buttato come strumento di forward engineering? No, neanche questo, ma 
il suo uso torna utile secondo me esclusivamente in fase di scaffolding, 
e solo nell'ambito di quei pochi paradigmi applicativi che possano 
considerarsi sufficientemente consolidati.
Usarlo in fase di sviluppo di dettaglio o di refactoring comporta un 
allungamento dei tempi di completamento del progetto di almeno un ordine 
di grandezza. Se poi il dominio applicativo è pure incerto, allora gli 
ordini di grandezza diventano due.
E spiegato molto meglio di quanto possa fare io in quest'articolo:
http://littletutorials.com/2008/05/15/13-reasons-for-umls-descent-into-darkness/
(già citato da altri in questo thread) con cui concordo largamente.
A quell'articolo ho tentato di aggiungere i miei 2 centesimi di cui 
sopra, che sono considerazioni più /astratte/, volte a (tentare di) 
provare che il fallimento di UML non è solo un fatto contingente ma 
abbia piuttosto caratteri di immanenza, per cui non c'è da aspettarsi 
grossi miglioramenti nel "foreseeable future", come direbbero in SDA 
(Bocconi).
Poi è ovvio che sbaglio.
Salute.

 integrate, che funzionano egregiamente.
Quale?


 Quale?
Quello a cui mi riferivo nel messaggio è un ORM Perl che si chiama 
DBIx::Class
http://search.cpan.org/dist/DBIx-Class/

 sposano malissimo con il codice strutturato).
Putroppo (per i talebani dell'OO :-) dentro ai metodi ci devi mettere
molto codice imperativo, che in UML va descritto con gli activity
diagrams, che poi sono in sostanza diagrammi di flussi modernizzati.
Per evitare il codice imperativo bisogna andare su ben altri tipi di
linguaggio, come Prolog.
Voglio dire: pensare di descrivere completamente un software senza mai
usare activity diagrams (e quindi senza algoritmi)  è una utopia.
Gli algoritmi dentro i metodi sono un pò il dna degli oggetti.

ispas ha scritto:

secondo me nella tua descrizione c'è un pò di tutto e ti posso dire che 
possono essere ben distinti...