Newsgroup: it.comp.java
Titolo: java e UML

Ciao a tutti.
Sono appena arrivato e quello che volevo chiedere non e' proprio una
domanda tecnica.
Volevo sapere se e quanto e' usato UML nella progettazione e sviluppo di
applicazioni java, cioe' se vi e' capitato di usarlo nello sviluppo delle
vostre applicazioni,
e se avete utilizzato solo i diagrammi delle classi o avche altri diagrammi,
come
gli use/case diagrams ( a cosa servono ??? boh ).
vale la pena di conoscerlo a fondo ?
ciao.
marco.

 wrote in message
9k6jee$gvl$1...@galileo.it.ip-plus.net...




guarda, conosco i fondamenti di java, lo sto studiando in questi
periodi, e affianco a java ho iniziato a studiare anche UML.
Io sono un programmatore C++, però trovo UML molto interessante,
e JAVA mi potrebbe tornare utile.
A mio avviso vale la pena, appena avrò una padronanza sufficiente per
UML, inizierò a usarlo per progettare le mie classi
cod

 e se avete utilizzato solo i diagrammi delle classi o avche altri
diagrammi,
Dipende dalle applicazioni che devi sviluppare.
Se l'applicazione è piccola, di basso costo, il budget è limitato, allora
non si usa neanche fare uno schemetto.
Se l'applicazione è più grossa, ci sono i soldi,  hai tempo, deve avere una
certa qualità, allora viene usato uml con tutti i vari diagrammi.
Molto spesso gli schemi uml li fa chi progetta il software e scrive i
documenti di analisi.
Chi programma però deve saper interpretare gli schemi, come pure chi fa
manutenzione.
Tutto dipende anche dal team di sviluppo, perché ci sono team che non usano
neanche il cvs ....
Io ultimamente uso uml per qualsiasi applicazione, piccola o grossa, perché
riesco a concettualizzare meglio, risparmio tempo sulla fase di debug e
rendo più riutilizzabile tutto (grazie ad una migliore concettualizzazione).
Prima mi mettevo davanti al pc e cominciavo a scrivere senza pensare più di
tanto, tagliando e incollando di qua e di là e molto spesso mi trovavo a
dover fare il reengineering di intere parti di programma.

Dipende da cosa devi sviluppare. Se sviluppi per gioco o per piccoli
progetti UML è anche troppo ridondante.
Se lavori in modo professionale su progetti di una certa importanza che
coinvolgono diverse persone allora UML diventa fondamentale per la
documentazione del progetto e la condivisione delle specifiche all'interno
del team.
Tieni presente che UML è estremamente vasto e puoi adattarlo alle tue
esigenze utilizzando solo i diagrammi che ritieni più opportuni.
Gli use-case sono tra quelli fondamentali perchè esprimono i requirements di
alto livello del tuo sistema, diciamo l'analisi funzionale ad alto livello.
Sono il punto di partenza per la realizzazione del tutto.
Ciao.
Alfredo

 wrote in message
news:RwE97.578$_07....@news.infostrada.it...



Acc! Jacobson si e' rivoltato nel letto :-D
Il discorso e' un po' lungo, ti consiglio di ragguagliarti su un libro, ad esempio "Object
Oriented Software Engeneering - A Use Case Drive Approach" proprio di Jacobson.
Ciao,
    Bruno.
|
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://bbruno.fasturl.it
|
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola
|


Potrebbe non essere la scelta giusta. Leggi la mia risposta sull'altro post, parliamone.
Ciao,
    Bruno.

|


 wrote in message
news:3b67af38.2620187@MI008IT-EFD01...



Ah si? Interessante posizione. 
Marco, ti consiglio vivamente di leggere in proposito, anche in rete trovi parecchio
materiale.
In generale, se posso, ti consiglio di essere piu' umile. 


 wrote in message
news:3b67bf6d.6769443@MI008IT-EFD01...



Non ti preoccupare, qui solitamente non si offende nessuno. E' solo che se si presentano
le proprie idee con calma e con la pazienza di ascoltare, discutere diventa piu' facile.


 wrote in message
news:3b67ca71.9589218@MI008IT-EFD01...


:

In generale si', anche se come hanno gia' detto dipende.
*Se* conosci bene UML e hai un buon prodotto che fa r e f/e, anche 
la velocita' di codifica ne risulta migliorata (se non conosci UML 
o il prodotto che usi e' scandente).
Oltre ai class diagram, i diagrammi piu' usati (nel mio caso, almeno) sono 
use case, sequence diagrams e activity.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

Quindi per il futuro penso che non usero' un gran che UML.
Mi pare che tu abbia colto un punto importante, un punto che peraltro
proprio in questo periodo e' al centro di uno scontro tra i
sostenitori di una certa metodologia, l'extreme programming (XP), e
quelli che hanno un approccio piu' classico, tradizionalista, ossia
quelli convinti della necessita' di investire molto sulla parte di
analisi e progettazione per ridurre al minimo i rischi in fase di
realizzazione, convinti cioe', sulla falsa riga di quanto fatto anche
in altre discipline, come ad esempio l'ingengneria civile (che infatti
mantiene sempre ben distinti il *progetto* dalla *costruzione* di un
immobile), della necessita' di dotarsi di strumenti e metodologie
adeguate, strumenti e metodologie a volte anche molto pesanti da
utilizzare ("monumental" per usare un termine di uno di cui non
ricordo il nome :-), 
Da questa premessa sembrerebbe ovvio che i sostenitori dell'XP non
vogliano saperne di strumenti di modellazione come l'UML, strumenti
che "distraggono" dal vero fulcro attorno a cui a loro avviso ruota un
progetto, il *codice*, e viceversa che i sostenitori dell'utilita' di
tale strumento invece, siano tutti convinti della necessita' di
utilizzare una metodologia "monumentale" per la realizzazione del
software...
Ma invece, come sempre, la realta' non e' mai bianca o nera come
spesso siamo portati a dipengerla, e alcuni dei sostenitori dell'XP
(Martin Fowler, quello che hai letto ad esempio:), sostengono la
possibilita' di stabilire un punto di collegamento tra le due visioni.
 Per approfondire queste nuova possibilita', che a mio avviso sono
molto promettenti, perche' consentono di prendere il meglio dei due
approcci, ossia la semplicita' dell'approccio XP, una metodologia
costruita tutta attorno al *codice* (per questo credo che possa
interessarti:), con le potenzialita' offerte da strumenti di
modellazione che utilizzano l'UML, pensati apposta per facilitare il
lavoro di analisi e progettazione del software, ma che sono integrati
direttamente pero', dentro al codice, insieme al quale possono
crescere.
Da qui il conio di un nuovo termine che mi pare colga bene il nocciolo
della questione: Extreme Modeling ;-)
Per approfondimenti sull'argomento puoi partire da
www.extrememodeling.org
.
ciao, Michele

approcci, ossia la semplicita' dell'approccio XP, 
Ecco, sul fatto che XP sia *semplice* non sarei cosi' immediato: richede
in effetti una disciplina notevole, spesso pari e superiore a quella di
metodologie piu' ingombranti. Ad esempio, pair-programming, test suites
e integrazione continua non vanno giu' tanto facilmente con moltissimi
sviluppatori, piu' usi al modello "faccio tutto io".
Il messaggio chiave di XP sulla semplicita' e' indirizzato allo
sviluppatore: ad esempio, in ambito OO, tende a ridurre la complessita'
inutile, un fattore che e' sempre piu presente tanto piu' nuovi
sviluppatori/architetti entrano nel mondo object-oriented: un tempo, per
dire, il problema era far capire a programmatori C o COBOL l'approccio
OO. Oggi, sempre di piu', e' far capire a programmatori OO overentusiasti
che mettere 5 livelli di delega e 18 interfacce tra due sottositemi in
nome di una possibile estensibilita' futura la cui probabilita' e minima
(ma che naturalmente aumentano la complessita' *adesso* :) non e', forse,
una buona idea. :-) 
Disegnando UML, i 5 livelli e le 18 interfacce si disegnano con poco
sforzo: scrivendo codice no. :-)


sforzo: scrivendo codice no. :-)
E' chiaro, spero di avere spiegato in che senso intendevo la
*semplicita'* dell'approccio: non certo con quello di mancanza di
rigorosita'! In questa direzione invece, sempre nell'ambito delle
metodologie cosiddette *agili*, esistono delle proposte interessanti a
mio avviso, che sto iniziando a valutare proprio in questo periodo,
metodologie meno *codificate* dell'XP, e quindi piu' facilmente
adottabili, come quella proposta ad esempio da Coockburn "Agile
Software Develpment".
Secondo Fowler, Coockburn e' riuscito, attraverso un'indagine durata
piu' di dieci anni sui diversi approcci utilizzati per realizzare
svariati progetti (egli e' l'unico a quanto ne so, ad avere fatto un
analisi cosi' vasta dei vari metodi implementati, e non essersi basato
solo sulla propria esperienza), a cogliere quegli aspetti essenziali
che rendono una metodologia *agile*, aspetti abbastanza facilmente
implementabili, attraverso l'adozione di una metodologia fatta su
*misura*  ...
L'hai gia' letto, e se si' cosa ne pensi in proposito? Mi
intereserebbe conosciere la tua opinione in proposito.
ciao, Michele

tutt'altra cosa - e si applica benissimo (pure) ad XP.
Su questo punto vorrei aggiungere qualcosa: in realta' credo che
l'approccio puro a XP sia in qualche modo in contraddizione con
l'adozione sistematica di strumenti come l'UML, dato che esiste
comunque una certa *distanza* tra il modello realizzato con l'UML e il
codice che verra' realizzato, aspetto quest'ultimo, che e' invece
fondamentale per quanto riguarda la filosofia XP, la lingua franca che
alla fine deve servire al team sia come documentazione, che come
modello, che come base per la progettazione di ulteriori
funzionalita'.
 Anche i test se vuoi, altro aspetto essenziale della filosofia XP,
visti a volte come dei strumenti propedeutici all'analisi e
progettazione (questo e' dimostrato dal fatto che in genere
l'implementazione risulta molto piu' veloce una volta che sono stati
predisposti i test), sembrano in contraddizione con un'adozione
pervasiva di strumenti come l'UML, strumenti che al contrario di
quanto avviene invece con il codice *non* consentono la
predisposizione immediata di strumenti di verifica della correttezza
dei modelli pensati, ma solo dopo essere passati alla fase di
codifica. 
E chiaro quindi che da questo punto di vista, sembra esserci una sorta
di contraddizione, se non teorica perlomeno pratica, tra l'adozione
della metodologia XP e quella di strumenti di modellazione come l'UML,
visti tutt'al piu' come linguaggi di comunicazione su supporti
temporanei come ad esempio una lavagna o un foglio sul quale disegnare
uno schizzo, ruolo che a mio avviso e' un po' riduttivo rispetto alle
potenzialita' offerte dallo strumento.
Tutto cio' per dire che invece, se i modelli UML diventassero
realmente testabili, e integrabili direttamente con il codice, la
presunta contraddizione tra l'UML e l'XP non solo svanirebbe di colpo,
ma l'UML potrebbe diventare una delle tecnologie abilitanti
all'adozione dell'XP, in quanto consentirebbe di migliorare
notevolmente tutte quelle pratiche che vengono utilizzate nell'XP.
A questo proposito credo che l'esperimento che stanno portando avanti,
integrando due diversi tools come ArgoUMl (o, meglio ancora, la
versione pacchetizzata che si chiama Poseidon, 
www.gentleware.com
),
strumento di modellazione che si basa sull'UNL, e Renew (un motore per
il disegno e l'esecuzione di reti di Petri), che viene utilizzato, una
volta che i modelli predisposti con Poesidon sono compilati
nell'apposito formato,  come una specie di UML Virtual Machine ... ;-)
A questo proposito ho letto un articolo davvero interessante (fra
l'altro molto breve e chiaro) nella sezione documentation del sito
www.extrememodeling.org
, che si intitola appunto "Extreme Modeling" di
Marco Boger, Tony Baier, Frank Wienverg, e Winfred Lamersdorf.
Sembrerebbe la chiusura del cerchio ... speriamo :-)
ciao, Michele


Gia'... per Fowler "visione" e' quanto mai azzeccato :-D
Secondo te che tipo di malleabilita' puo' avere un software costruito con questo metodo?
In che modo il metodo di Fowler permette di "abbracciare il cambiamento"? Costera' di piu'
o di meno? 
Nota poi la differenza che si nota fra i concetti espressi in "Agile Modeling"
(
www.extreme-modeling.com
) e XM (
www.extrememodeling.org
). Fossi in te mi terrei piu' in
contatto con AM che con XM. Il cambiamento di nome secondo me non e' casuale...
Ultima osservazione tratta dai siti citati:
"AM is an attitude, not a prescriptive process"
"EM is a new software development process"



Stra-esatto!
Allora, a quando l'adozione di XP nella tua azienda? :-D



Attenzione, Cockburn non prescrive un processo ma (cito) "a supplement to existing
methods": nello specifico una serie di pratiche che sono una estensione di quelle XP: a
volte un espansione (
p.es
 "Active Stakeholder Participation" -> OnSiteCustomer), a volte
le stesse ("Collective Ownership" -> CollectiveOwnership), a volte pratiche diverse o
nuove (Apply The Right Artifact(s)).


Sembrerebbe la chiusura del cerchio ... speriamo :-)
O la quadratura, del cerchio :-)


nuove (Apply The Right Artifact(s)).
Cito ancora, in caso puoi scrivere a Fowler ;-)
"Cockburn's Crystal Family 
Alistair Cockburn has been working on methodology ever since he was
tasked by IBM to write about methodology in the early 90's. His
approach is unlike most methodologists, however. Instead of building
on solely personal experience to build a theory of how things should
be done, he supplements his direct experience with actively seeking to
interview projects to see how they work. Furthermore he isn't afraid
to alter his views based on his discoveries: all of which make him my
favorite methodologist.
His book, Surviving Object-Oriented Projects, was his first piece of
advice on running projects, and remains my number one book
recommendation for running iterative projects.
Since that book he's explored agile methods further, coming up with
the Crystal family of methodologies. It's a family because he believes
that different kinds of projects require different kinds of
methodologies. He looks into this variation along two axes: the number
of people in the project, and the consequences of errors. Each
methodology fits into a different part of the grid, so a 40 person
project that can lose discretionary money has a different methodology
than a six person life-critical project.
The Crystals share a human orientation with XP, but this
people-centeredness is done in a different way. Alistair considers
that people find it hard to follow a disciplined process, thus rather
than follow XP's high discipline, Alistair explores the least
disciplined methodology that could still succeed, consciously trading
off productivity for ease of execution. He thus considers that
although Crystal is less productive than XP, more people will be able
to follow it."
Come vedi Coockburn "esplora la metodologia meno disciplinata che
potrebbe ancora avere successo " ... ovvero, detto in altri termini,
proprio cio' che avevo cercato di spiegare io: egli ha cercato di
trovare gli aspetti essenziali che devono essere rispettati affinche'
una metodologia su *misura* (come detto egli non prescrive LA
metodologia), possa e debba avere ancora successo. Spero di essermi
chiarito ;-)
ciao, Michele

O la quadratura, del cerchio :-)
Per quanto abbia tentato, non sono mai riuscito a far diventare un
cerchio un quadrato: alla fine quindi ho deciso di rinunciare ;-)
ciao, Michele

"EM is a new software development process"
Faro' attenzione ;-)
ciao Michele


Si, ma vedi, non prescrive un metodo o un processo. Lui non ti sta dicendo quali passi tu
devi eseguire per raggiungere il risultato, ne' tantomeno descrive una notazione (per lui
e' sufficiente che ne sia scelta e condivisa una). Fowler sta cercando di venderti un
metodo.



Gia'... vorra' dire qualcosa :-)?



Gia', perche' fra dare delle indicazioni e definire un nuovo processo, cercando di
venderlo, c'e' molta differenza.


Marco Boger, Tony Baier, Frank Wienverg, e Winfred Lamersdorf.
Devo darci un'occhiata. ;-)


metodo.
Ok, messaggio recepito, Fowler bisogna leggerlo con il beneficio
dell'inventario :-)
ciao, Michele

Gia'... vorra' dire qualcosa :-)?
Che "ci stiamo attrezzando per i miracoli"? :-)
ciao, Michele

Devo darci un'occhiata. ;-)
Fammi sapere cosa ne pensi.
ciao, Michele

tazza.
Il mio problema e' che *non* sono ancora riuscito a riempirla: se
penso poi a quanto tempo ci vorra' per svuotarla quasi quasi rinuncio
fin dall'inzio all'impresa *impossibile* :-))
ciao, Michele

eventuale switch di strumento. 
Piu' che altro, c'e' una marea di trucchetti che aiutano a
fare le cose efficientemente: se non li conosci, puoi farle lo stesso
ma in modo molto piu' ingombrante. Cio' che non sopporto (piu') di 
Rose e' la (in)compatibilita' con UML1.3, i bug delle first-release
e il fatto che gli unici grafici veramente utilizzabili sono quelli
di classe - forse tra i meno utili in effetti.



Gia' :-)


Ma, se non ho capito male c'e' di piu' e di meglio:
(e per fortuna :-D)

Ma il problema e': tutto questo serve veramente a qualcosa?
Siamo sicuri che introducendo tutta questa complessita' avremo dei risultati migliori? Sei
sicuro che tu non sia semplicemente affascinato dalla complessita? Dall'attivita' di
design versus quella di codifica? 
Dai, leggi l'articolo :-) e guarda che cantonata prenderebbero i due amici partendo dal
design (diagramma UML).



Vedrai che dovrai svuotarla, e prima lo fai meglio e'. In bocca al lupo!


implementa tutte e 12 le pratiche.
In sostanza si', anche se credo che alcune delle regole siano da
prendere con il beneficio dell'inventario: ad esempio, capisco che
sarebbe meraviglioso poter avere a disposizione sempre del personale
del cliente che lavora a fianco a fianco dei programmatori ... pero'
sinceramente non me la sento, ad esempio, di chiedere di avere a
disposizione il responsabile della produzione (che nel mio caso
sarebbe la persona piu' adatta, e probabilmente disponibile) ...
Tu si'?!
Ora non so se mancando questa condizione ad esempio, si possa parlare
ancora di XP, di XP pura o quant'altro, ma probabilmente la questione
e' oziosa, dato che si sa in anticipo che andra' comunque finire in
quel modo...
ciao, Michele

design (diagramma UML).
Ti prometto che ti rispondo su questo punto non appena lo avro' letto
:-)
ciao, Michele

Vedrai che dovrai svuotarla, e prima lo fai meglio e'. In bocca al lupo!
Quello che intendevo dire, e' che sto pensando in tutta serieta' di
rinunciare a *riempirla*, la tazza, per evitare poi alla fine di
essere costretto comunque a *svuotarla* ... :-)
ciao, Michele


Uh? Non ho capito.


:-)
Yuck! Letto, letto ... davvero illuminante, ti ringrazio per la
preziosa risorsa che mi hai indicato.
Per quanto riguarda la cantonata e il design in UML non posso che
darti atto del pericolo incombente ...: e' chiaro che alla luce di
questo approccio bisogna quantomeno ripensare al suo possibile
utilizzo ... di piu' in questo momento non so dirti, ci devo
riflettere un po' su, probabilmente dovro' fare anch'io qualche test
.. :-)
Un dubbio che mi frulla per la testa: ma l'architettura e i patterns
come si sposano con la filosofia della *semplicita'*? Ha ancora senso,
e se si' attraverso quali filtri, utilizzare dei patterns
riconosciuti, che possono introdurre nel sistema una complessita'
indesiderata? E per quanto riguarda la scelta dell'architettura del
sistema, non ti sembra in qualche modo contraddizione con il principio
di ritardare il piu' possibile le scelte che aggiungono complessita'
indesiderate al sistema?
ciao, Michele

Uh? Non ho capito.
E' oziosa nel senso che (nell'esempio che ti sto portando) non e' una
opzione praticabile purtroppo ... 
ciao, Michele

un ponte su un fiume."
Ecco, questo e' eccessivo. :-)
Niente principi di autorita', ma Rambaugh, Booch e Jacobson non hanno
ideato UML (o OMT, o la Booch-N, o gli use case) perche' si sono
svegliati un bel mattino con l'idea :), ma come distillato di quello che
nella loro esperienza *ha* funzionato.
E non e' che ne hanno avuta poca. ;-)
Magari e' diverso l'ambito di applicazione (progetto IBM da 80 persone 
per il governo contro sito web per il fruttivendolo sotto casa), ma
qui rischiamo di buttare via il bambino con l'acqua calda. 


qui rischiamo di buttare via il bambino con l'acqua calda. 
*Rischiamo* solo pero', alla fine vedrai che butteremo via solo
l'acqua *sporca* (non ho capito cosa hai contro l'acqua calda :-)
ciao, Michele

(non ho capito cosa hai contro l'acqua calda :-)
E' che in Norvegia se ne fa un gran uso ;-)



Prova, poi ne parleremo forse ancora :-D



Uhm... non capisco, in XP si parla di metafora, non di architettura. Puoi spiegarti
meglio?



Peccato. Fate in modo comunque di avere una soluzione alternativa (videoconferenza, linea
dedicata, telefono)



Nessuno vuole buttare via niente, stiamo solo discutende delle opportunita' di uso che
hanno certi strumenti.


dedicata, telefono)
In effetti e' quello a cui sto pensando: peraltro la persona
competente e' direttamente interessata e spinge molto nella direzione
giusta. Vedremo.
ciao, Michele

meglio?
E gia' ... diciamo che con la scelta dell'architettura intendo la
scelta della tecnologia da impiegare (ad esempio java enterprise
piuttosto che asp, application server piuttosto che php ecc...) e
anche l'impostazione generale da seguire, tipo MVC ecc.
Ad ogni modo quella della metafora e' una delle cose che non ho
capito: piu' in dettaglio, non ho capito bene ne' cos'e' ne' quali
vantaggi comporta ... :-(
ciao, Michele

Prova, poi ne parleremo forse ancora :-D
Ok, anche se per quello che avevo in mente (Poseidon) mi pare che
ancora non ci siamo: quando sara' pronto il tutto ci ritornero' su,
per il momento posticipiamo una scelta che ancora e' prematura: fatto
presto a imparare l'approccio adattativo? ... :-))
ciao, Michele

ancora non ci siamo ...
detto meglio: per la possibilita' di testare e integrare direttamente
i modelli UML nel codice con Poseidon mi pare che ancora non ci siamo.
Come strumento di modellazione per l'UML, invece mi pare valido, anche
se non sono in grado di fare raffronti con altri prodotti.
ciao, Michele


Uhm... dovresti provare a leggerti un capitolo del libro di wake, XP eXplored, che non e'
granche' ma spiega bene il concetto di metafora... aspetta che vedo se lo trovo online...
no, non c'e' piu', pero' se ti iscrivi a xp-italy lo trovi nella sezione files: il
capitolo e' il 7, il link assoluto e'
http://groups.yahoo.com/group/extremeprogramming-it/files/XP-Explored.pdf



Facendo un piccolo conto, direi circa 4000 ore. Un po' tantine, neh? Comunque adesso ci
sono delle strutture apposta che ti fanno il training dell'intero team in un paio di mesi.
Ad esempio il mio mentor lo fa: 
www.xplabs.com



http://groups.yahoo.com/group/extremeprogramming-it/files/XP-Explored.pdf
Ti ringrazio per l'informazione, vedro' di iscrivermi non appena mi
metto a posto con l'indirizzo e-mail.
ciao, Michele

Ad esempio il mio mentor lo fa: 
www.xplabs.com
Questo mi pare eccessivo per l'economia della nostra piccola struttura
... forse e' meglio se partiamo subito seguendo il primo insegnamento
dell'XP: "mai fasciarsi la testa prima di essersi fatti male" :-))
Forse non e' proprio tratto dal manuale dell'XP (che infatti *non*
esiste:-), ma credo che su questo possa essere d'accordo perfino la
nonna di Kent Beck, che cosi' viene citata in "Extreme Programming
Explained", pag. 105: 
"Fortunately, most folks can unlearn the habit of "borrowing trouble"
(as my grandmother called it)" :-)))
ciao, Michele

opportunita' di uso che hanno certi strumenti.
Molto spesso, il problema effettivo non e' se usare UML o XP - ma far
arrivare all'industria UML/RUP e XP o LP in modo che non siano distorti
oltre riconoscibilita'. 


>svuotarla.". Io ti consiglio di svuotare la tazza.
... ditemi come svuotare la tazza. Bruno, sono sicuro che gia' mi hai
inviato, alcuni mesi fa, il link all'articolo di XP, naturalmente non lo
trovo (mea culpa), potresti rispedirmelo?
E poi, sto studiando parecchio per prepararmi al meglio al mio prossimo
ruolo di "Java Software Engineer" (mi fa un po' ridere, usata su di me): UML
(con cui gia' lavoro), un po' XP, Blueprints di sun, pattern (grazie anche a
Cristiano per alcuni suggerimenti di molti mesi fa a questo riguardo).
Tanto materiale, troppo? potreste indicarmi tutti i link (e libri, articoli,
ecc.) che DEVO studiare assolutamente per partire col piede giusto? Se
magari non vi dispiace troppo, potreste inviarli anche sulla mia casella
personale ;) Per i primi commenti dovrete pero' aspettare che torni dalle
vacanze... :)
ciao!
e non sognatevi di fare queste discussioni in privato, qui ascoltiamo e
impariamo!!
--
Federico


L'industria siamo noi :-)



Tranquillo, il NG e' qui apposta per noi!


L'industria siamo noi :-)
Questo vorrei fosse vero. Sarei, almeno, meno povero di quanto sono. :-)



Vabbe' adesso non buttarti giu' cosi! 
Allora, lo scriviamo 'sto libro?


ah, una discussione cosi' interessante ed io mi ritrovo dopo le ferie
senza aver detto la mia....
per questo, mi ritengo ufficialmente offeso e deluso, e quindi mi
ritirero' un mese a riprogrammare in mmix tutti gli esempi di Knuth...

-- 
         ______
        /_____/\             Ugo Landini
       /____ \\ \            Education Technical Supervisor
      /_____\ \\ /           Sun Educational Services
     /_____/ \/ / /          
    /_____/ /   \//\         SUN Microsystems Italia S.p.A.
    \_____\//\   / /         Via Romagnosi, 4
     \_____/ / /\ /          00196 - Rome (RM) - Italy
      \_____/ \\ \           @mail : 
ugo.l...@sun.com
       \_____\ \\            Phone : +39 (0)  6 36708.682
        \_____\/             GSM   : +39 (0)  335 7766651

ritirero' un mese a riprogrammare in mmix tutti gli esempi di Knuth...
Vietato ritirarsi! Piu' opinioni ci sono, piu' e' divertente e piu'
s'impara. :-)


tanto gia' sapete come la penso, no? ;)
uL



Come non detto, un mio collega me ne ha segnalato uno giusto ora:
http://online.infomedia.it/riviste/cp/101/articolo07/index.htm
Devo ancora leggerlo bene. E' un po' troppo schematico, ma direi che i contenuti ci sono
abbastanza, vi diro' poi in dettaglio.


>tanto gia' sapete come la penso, no? ;)
Uhm...
AFAIK tu sei iscritto a xp-it, hai parlato spesso con Francesco e forse hai anche seguito
un suo crash-course, ma sei storicamente anche un grande sostenitore di UML e pattern,
quindi... come la pensi? Sei un caso interessante :-D


 
Piu' pattern di UML, comunque. UML, per me, e' sempre stata una
notazione utile per il suo valore come standard di comunicazione
"universale". Per i pattern, il discorso e' tutto sull'anticipazionismo
o meno, quindi sul modo di utilizzarli. L'importanza ed il valore dello
studio di ogni singolo pattern (GoF o meno) non e' da mettere in
discussione, semmai l'uso  e l'abuso, o meglio, il momento in cui
applicarli puo' essere oggetto di simpatiche discussioni.
Se vuoi, questo e' come quando si utilizza un linguaggio eccessivo per
un particolare (semplice) problema: anche questo e' overdesign, ma il
problema non e' nel linguaggio in se' quanto nella sua applicazione, o
meglio nel suo "momento" di applicazione.
Il linguaggio piu' potente potrebbe infatti  diventare necessario piu'
in la' nel tempo (che so, al crescere degli utenti, del database, ecc.
ecc.), ma potrebbe anche non diventarlo mai. Anche questa scelta di
partire subito con un linguaggio "perche' forse poi se..." e' una
strategic closure (leggere B.Meyer per chi non conosce Open/Closed
principle) che potrebbe pero' rivelarsi un overdesign (o
overarchitecturing, l'ho inventato ora). Questo vale per qualsiasi
linguaggio, ma, ad un altro livello, anche per eventuali framework (o
middleware, o qualsiasi altro nome vi piaccia).
Ad esempio il dibattito su EJB o non EJB (vedasi xp-it), che e' molto
interessante ma dovrebbe essere approfondito, non tiene conto del
parallelismo che si puo' fare fra la JVM ed un EJB Container (in
relazione con le classi Java e gli eJB) per cui, in fondo, anche la JVM
non e' altro che un fornitore di servizi per le nostre classi (dove i
servizi sono la garbage collection, le caratteristiche OO, le vaste
librerie, ecc.) ne piu' ne' meno di un EJB container che fornisce
servizi come le transazioni distribuite, ecc ai bean.
Comunque, meno male che qualcuno ci paga per
fare/insegnare/promuovere/ecc. quello che ci piace, altrimenti saremmo
messi male... e magari dovremmo fare delle form in VB per campare. Si,
non c'entra niente, ma ho sonno e mi andava di dirlo.
uL

Allora, lo scriviamo 'sto libro?
In effetti, ti volevo riproporre la cosa. :-)


ho tempo di uscire con qualche nuova norvegese o giocare a Diablo II. :-)
                                ^^^^^^^^^^^^^^^
La più interessante applicazione OO che abbia mai sentito :-)
-- 
Ciao
	Fabrizio C.


Arf! Allora qualcuno che ascolta c'e'  :-D
Okay, state sintonizzati, penso che in capo a un paio di giorni riusciro' a terminare la
risposta al post di Cristiano. 



Son qui, la mia mail la conosci :-D
