java e UML
Marco
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.
Anteo
Se vuoi progettare una bomba nucleare dovresti usarlo. :-)
Ciao, Anteo.
Marco <ma...@icona.it> wrote in message
9k6jee$gvl$1...@galileo.it.ip-plus.net...
cod
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
Ettore
>
> 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,
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.
Alf
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
Marco
Comunque io ho letto qualche cosa su UML nel libro "UML Distilled", e devo
dire
che non mi ha entusiasmato affatto.
In particolare per i diagrammi use/case, mi sembrano davvero inutili e senza
scopo.
Voglio dire, dopo che hai costruito un diagramma use/case che te ne fai,
puoi usarlo
in qualche modo per ricavare il diagramma delle classi ? ( che e' forse
l'unico che mi sembra
possa avere una qualche utilita' ), ma come ? In pratica il diagramma
use/case mi sembra solo
una perdita di tempo.
Anche il diagramma delle classi fa perdere parecchio tempo, penso che puo'
essere utile come
documentazione ( meglio la javadoc comunque ), ma in questo caso devi prima
scrivere il codice
delle classi e poi usare al limite tool come TogheterJ che da quello ti
ricavano il diagrammma.
Progettare un'applicazione partendo dal diagramma delle classi dal quale
ricavare gli scheletri delle classi stesse
( sempre con TogheterJ ) mi sembra una perdita di tempo, e poi nei diagrammi
non si riesce a rappresentare
in maniera completa tutte le caratteristiche di una classe le relazioni tra
le classi ( vedi ad esempio un Singleton ).
Quindi per il futuro penso che non usero' un gran che UML.
ciao.
marco.
"Alf" <alf...@iol.it> wrote in message
news:RwE97.578$_07....@news.infostrada.it...
Bruno Bossola
>applicazioni java, cioe' se vi e' capitato di usarlo nello sviluppo delle
>
Si. In generale UML si puo' usare in diversi modi:
- per fare attivita' di design durante l'analoga fase (se usi waterfall, ad esempio, il
ciclo e' analisi -> design -> codice -> test)
- per realizzare documentazione partendo da un sistema preesistente
- come "lingua franca" quando e' necessario spiegarsi vicendevolmente dei concetti.
Io lo uso in questo ultimo modo: un rapido schizzo UML a volte chiarisce piu' di mille
parole :-D Non realizzo mai comunque documenti UML, il mio design e' nel codice (ah, uso
XP)
>vale la pena di conoscerlo a fondo?
>
Si, e' come l'inglese :-)
Ma non e' necessario conoscere "tutto UML", e' sufficiente conoscere il pezzo necessario
nella propria realta'. UML e' infatti immenso, e volutamente un po' complicato e mostrato
sempre come complicato, altrimenti come farebbero a vendere i libri e i corsi?
Io conosco a grandi linee UML, e ho approfondito solo i diagrammi che uso (vedi sotto).
>e se avete utilizzato solo i diagrammi delle classi
>o avche altri diagrammi
>
I diagrammi che uso di piu', ma sempre e solo a livello di schizzo, sono (in ordine di
frequenza) collaboration, sequence, usecase, class, deployment. In generale comunque nel
software engineering odierno si da' erroneamente molta importanza ai class diagram, che
mostra un modello statico del software. Invece nell'OO e' molto piu' importante la
dinamica del sistema: esso e' un insieme di oggetti che collaborano, e da questa
collaborazione ne nasce il valore per l'utente, e per il quale l'utente e' disposto a
pagare :-D (ah, sempre i soldi alla fine!).
> come gli use/case diagrams ( a cosa servono ??? boh ).
>
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
|
Bruno Bossola
>
Ciao,
Bruno.
|
Marco
bastato.
In effetti quello che mi aspettavo da UML era molto di piu' di quello che ho
visto.
Ad esempio riuscire a ricavare il diagramma delle classi da quello degli
use/case, cosa che penso
sia impossibile, a meno di avere un software pensante ( tipo intelligenza
artificiale ).
Quindi resto della mia idea, glimuse/case sono una perdita di tempo in fase
di progettazione,
forse possono servire per illustrare il progetto ad altre persone, ma allora
e' solamente
una cosa utile per la documentazione, non per la progettazione.
Paradossalmente si puo' dire che gli use/case dovrebbero essere fatti
partendo dal progetto
gia' fatto ( sorgenti delle classi ), l'esatto contrario di quello per cui
sono stai inventati.
"Bruno Bossola" <bbos...@hotmail.com> wrote in message
news:3b67af38.2620187@MI008IT-EFD01...
Bruno Bossola
>bastato.
>
troppo su alcuni punti. Non penso pero' che un solo libro sia in grado di spiegarti un
argomento complesso come il software engineering.
>In effetti quello che mi aspettavo da UML era molto di piu' di quello che ho
>visto.
>
Aspettativa normale, visto quanto lo spingono e quanto costano libri e corsi :-)
>Ad esempio riuscire a ricavare il diagramma delle classi da quello degli
>use/case, cosa che penso sia impossibile, a meno di avere un software pensante
>(tipo intelligenza artificiale).
>
Non e' quello a cui servono.
>Quindi resto della mia idea, glimuse/case sono una perdita di tempo in fase
>di progettazione, forse possono servire per illustrare il progetto ad altre
>persone, ma allora e' solamente una cosa utile per la documentazione, non
>per la progettazione.
>
Come puoi giudicare l'utilita' di qualcosa senza neanche sapere cos'e'? (per tua stessa
ammissione nel post originale)
>Paradossalmente si puo' dire che gli use/case dovrebbero essere fatti
>partendo dal progetto gia' fatto (sorgenti delle classi), l'esatto
>contrario di quello per cui sono stai inventati.
>
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.
Marco
Il mio dubbio riguardava a cosa effetivamente possono servire gli use/case,
non mi sono fatto capire bene.
Leggendo il libro credevo che potessero offrire certe funzionalita' per cui
non sono preposti, mi sono sbagliato.
Certo forse lo sviluppo ideale e ottimale di un progetto prevede di partire
dagli use/case, passare attraverso
gli altri diagrammi, arrivare al diagramma delle classi e alla fine fare
l'implementazione.
Questo penso sia il percorso ottimale, purtroppo spesso manca il tempo e si
passa subito all'implementazione.
comunque scusa se ho usato dei toni troppo pesanti, non l'ho fatto apposta,
per il futuro cerchero' di state piu'
attento.
ciao.
marco
"Bruno Bossola" <bbos...@hotmail.com> wrote in message
news:3b67bf6d.6769443@MI008IT-EFD01...
Bruno Bossola
>beh.... effetivamente ho sono stato un po' pesante nel giudizio
>
>Certo forse lo sviluppo ideale e ottimale di un progetto prevede di partire
>dagli use/case, passare attraverso gli altri diagrammi, arrivare al diagramma
>delle classi e alla fine fare l'implementazione.
>
Questo e' un metodo di software engineering molto usato, la cui provenienza e' proprio di
Jacobson (Use Case driven approach)
>Questo penso sia il percorso ottimale, purtroppo spesso manca il tempo e si
>passa subito all'implementazione.
>
Gia'. E soprattutto e' poi difficile manterere aggiornati tutti quei diagrammi. E' per
questo che ultimanente sono nati degli approcci chiamati "lightweight" al software
engineering, il piu' conosciuto dei quali e' attualmente XP. A questo link trovi una
introduzione abbastanza accurata:
http://www-106.ibm.com/developerworks/ibm/library/j-xp/index.html
Comunque, attenzione, XP non nega i valori portati dal software engineering e dai principi
di analisi e desing OO, anzi, li porta all'estremo! E' solo che in XP i documenti (quelli
che ti fanno perdere tempo) non sono poi cosi' importanti.
>comunque scusa se ho usato dei toni troppo pesanti, non l'ho fatto apposta,
>per il futuro cerchero' di stare piu' attento.
>
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.
Marco
approfondire XP e ti faro' sapere.
ciao.
marco
"Bruno Bossola" <bbos...@hotmail.com> wrote in message
news:3b67ca71.9589218@MI008IT-EFD01...
Cristiano Sadun
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
Michele Bendazzoli
[...]
>Progettare un'applicazione partendo dal diagramma delle classi dal quale
>ricavare gli scheletri delle classi stesse
>( sempre con TogheterJ ) mi sembra una perdita di tempo, e poi nei diagrammi
>non si riesce a rappresentare
>in maniera completa tutte le caratteristiche di una classe le relazioni tra
>le classi ( vedi ad esempio un Singleton ).
>
>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
Cristiano Sadun
<3b724ce3...@news.galactica.it>:
>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 :-),
Qualche commento.
-Molte metodologie sono "grosse" perche' sviluppate per progetti
governativi US, che necessitano di un sacco di carta per dimostrare chi
e' responsabile di cosa ;-). Esistono metodologie leggere che funzionano
benone: il punto e' che - come al solito - anche se non lo sai hai
*sempre* un processo quando sviluppi software.. tanto vale controllarlo.
;-)
-"Investire molto sulla parte di analisi e progettazione"
e' qualcosa che si fa sia in XP che no. In XP si cerca semplicemente
di tradurre idee *immediatamente* in pezzi di codice, senza usare
necessariamente un linguaggio intermedio, a meno che non sia necessario.
Ma quando e' necessario, e' necessario. :-)
-Per quanto riguards UML, il punto e' che UML e' stata proposto, usato e
applicato quasi sempre come un linguaggio di (post-) documentazione,
con un modello "architetto/dio, sviluppatore/schiavo" :)
Usare UML attivamente, *durante* lo sviluppo, come linguaggio per
comunicare e comparare idee ignorando dettagli irrilevanti e'
tutt'altra cosa - e si applica benissimo (pure) ad XP.
-La stragrande maggioranza della gente che propone o usa XP e'
la stessa che proponeva o usava linguaggi grafici (UML o altri)
e che stressava sul design.
C'e' da dire che con linguaggi relativamente chiari come Java
la necessita' di un linguaggio intermedio diminuisce.
>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.
Appunto. La contraddizione e' negli occhi di chi guarda. ;-)
XP integra e semi-formalizza aspetti chiave del processo di costruzione
di software che prima non erano particolarmente enfatizzati.
> 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,
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. :-)
Michele Bendazzoli
wrote:
>-"Investire molto sulla parte di analisi e progettazione"
>e' qualcosa che si fa sia in XP che no. In XP si cerca semplicemente
>di tradurre idee *immediatamente* in pezzi di codice, senza usare
>necessariamente un linguaggio intermedio, a meno che non sia necessario.
>Ma quando e' necessario, e' necessario. :-)
Hai ragione a puntualizzare, anzi ti ringrazio per l'aiuto a chiarire
meglio quanto ho scritto: in effetti avevo cercato di puntualizzare
che la presunta contrapposizione tra XP (e le altre metodologie
*agili* ... :) e l'utilizzo di strumenti come l'UML e' in realta' piu'
apparente che reale, ma probabilmente non ci sono riuscito come
speravo :-)
[...]
>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".
In effetti anche qui hai ragione e ti ringrazio per la precisazione:
credo che il termine piu' corretto sia *agile* (che anche in inglese
ha lo stesso significato ;-)
>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. :-)
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
Michele Bendazzoli
wrote:
>Usare UML attivamente, *durante* lo sviluppo, come linguaggio per
>comunicare e comparare idee ignorando dettagli irrilevanti e'
>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
Bruno Bossola
Ciao,
prima di tutto il mio team usa XP, tutte e 12 le pratiche, quindi penso di potere dare
il mio contributo a questa discussione molto interessante! Yep! Finalmente! Comunque se ti
interessa XP, e in special modo in Italia, iscriviti alla lista su yahoogroups gemella di
quella americana, ovvero http://groups.yahoo.com/group/extremeprogramming-it/
>...metodologia...
metodologia -> studio dei metodi :-D
>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...
>
Dire che gli svluppatori XP non vogliono saperne di UML e' fortissimo! Noi XPers
conosciamo UML, e lo usiamo correntemente. Solo non lo utilizziamo per fare BDUF (Big
Design Up Front, ovvero grosso dedign anticipazionista) o anche solo DUF, come hai detto
anche tu. XP e' un metodo che comprende un processo (le 12 pratiche) e una notazione, che
normalmente e' UML, ma che potrebbe anche essere qualunque altra.
>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.
>
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"
Bruno Bossola
>-Molte metodologie sono "grosse" perche' sviluppate per progetti
>governativi US, che necessitano di un sacco di carta per dimostrare chi
>e' responsabile di cosa ;-). Esistono metodologie leggere che funzionano
>benone: il punto e' che - come al solito - anche se non lo sai hai
>*sempre* un processo quando sviluppi software.. tanto vale controllarlo.
>;-)
>
Ya!
>-"Investire molto sulla parte di analisi e progettazione"
>e' qualcosa che si fa sia in XP che no. In XP si cerca semplicemente
>di tradurre idee *immediatamente* in pezzi di codice, senza usare
>necessariamente un linguaggio intermedio, a meno che non sia necessario.
>Ma quando e' necessario, e' necessario. :-)
>
Ya! Comunque ti posso garantire che se cerchi di fare le cose in modo semplice,
incentrando il tuo sviluppo sul test-first incrementale raramente e' necessario.
E di design, in XP, se ne fa parecchio, e' solo che lo si fa dopo. Il microciclo in XP
diventa test -> codice -> design
>-La stragrande maggioranza della gente che propone o usa XP e'
>la stessa che proponeva o usava linguaggi grafici (UML o altri)
>e che stressava sul design.
>
Giustissimo! Vedi Zio Bob (Robert Martin) ad esempio. Ha rotto le balle per anni sui
principi di design :-) come DIP, OCP, LSP
(http://www.objectmentor.com/publications/articlesByDate.html) e non e' che adesso li
rinnega, anzi!!! Un Xper deve conoscere *perfettamente* i principi di OOA / OOD: e' solo
che li applica non in modo anticipato.
>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".
>
Stra-esatto!
Ed inoltre, prima di iniziare ad usare XP, devi studiarti TUTTO quello che c'e' sul OOA /
OOD. E continuare a farlo tutti i giorni! Per farvi un esempio, io conosco tutti i DP del
GOF, a memoria: posso citarvi le caratteristiche di ognuno, ed elencarveli sia per tipo
che per ordine alfabetico :-)
>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. :-)
>
Stra-esatto!
Allora, a quando l'adozione di XP nella tua azienda? :-D
Bruno Bossola
>[...]
>>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".
>
>In effetti anche qui hai ragione e ti ringrazio per la precisazione:
>credo che il termine piu' corretto sia *agile* (che anche in inglese
>ha lo stesso significato ;-)
>
Uhm... potremmo dire che XP e' semplice, ma metterla in pratica no :-)
Dire che e' "agile" e' vero, ma sposta il fuoco su un aspetto di XP. In realta' le
pratiche di XP sono semplici, ma sono difficili da mettere in atto e richiedono come dice
giustamente Cristiano una disciplina fortissima.
>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".
>
XP non e' affatto "codificata", ma semplicemente tende alla specifica anche di un
processo. E nota che XP e' un metodo molto adattabile. Non esiste infatti il Metodo XP
(dovrei scriverlo tutto maiuscolo :-)), ma in genere ogni team sceglie di implementare le
pratiche nel modo piu' adatto per la propria realta'.
>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* ...
>
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)).
Bruno Bossola
>On Thu, 09 Aug 2001 10:22:32 GMT, crs...@tin.it (Cristiano Sadun)
>wrote:
>
>>Usare UML attivamente, *durante* lo sviluppo, come linguaggio per
>>comunicare e comparare idee ignorando dettagli irrilevanti e'
>>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...
>
Non esiste l'approccio "puro" a XP, XP e' un metodo flessibile, non rigido. Nessuno vieta
di fare diagrammi, documentazione, quello che ti pare se ti serve o se te lo chiede il
cliente.
>... 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'.
>
In XP la lingua franca e' il codice, che tutti conoscono (vedi PairProgramming,
CollectiveOwnership, etc.)
>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)...
>
Attenzione, non funziona cosi. I test sono scritti incrementalmente, e ogni nuovo test
porta in genere a costruire nuovo codice che implementa il test.
Per avere le idee piu' chiarepuoi leggere questo:
http://www.objectmentor.com/publications/xpepisode.htm
>... 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.
>
Il punto non e' UML: il punto e' il design anticipato, il (B)DUF ((Big) Design Up Front)
che porta con se innata complessita, pagando un alto prezzo cercando di anticipare
cambiamenti che e' possibile non si verifichino mai.
>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.
>
Il motivo e' che UML e' stato disegnato da anticipazionisti, persone convinte che
realizzare un sistema software sia analogo a realizzare un ponte su un fiume.
>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...
>
Non c'e' contraddizione fra UML e XP: XP puo' usare UML, ma non in modo anticipazionista.
>...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 ... ;-)
>
Vedremo. Per ora mi sembra un po' troppo complesso, e poco automatizzabile, se non a iun
prezzo per ora molto alto.
>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.
>
Si, presentato a XP200. L'ho letto un po' di tempo fa ma adesso mi rinfresco...
Mah... come gia' allora la prima fase mi da un po' fastidio: "XP... has been
criticised.... leaving behind design". In XP si fa design, un sacco! Bisogna conoscere
*perfettamente* i principi di design, solo che li si applica _dopo_, non in modo
anticipato.
Okay, comunque adesso mi sforzo di rileggerlo con attenzione e poi commento.
>Sembrerebbe la chiusura del cerchio ... speriamo :-)
O la quadratura, del cerchio :-)
Michele Bendazzoli
wrote:
>XP non e' affatto "codificata", ma semplicemente tende alla specifica anche di un
>processo. E nota che XP e' un metodo molto adattabile. Non esiste infatti il Metodo XP
>(dovrei scriverlo tutto maiuscolo :-)), ma in genere ogni team sceglie di implementare le
>pratiche nel modo piu' adatto per la propria realta'.
Ok, vedo che passate ogni termine che uso sotto la lente di
ingrandimento ... :-)
Facciamo cosi' mi richiamo all'auctoritas cosi' mi levo d'impiccio:-)
Cosi' Flower:
"On this platform XP builds an evolutionary design process that relies
on refactoring a simple base system with every iteration. All design
is centered around the current iteration with no design done for
anticipated future needs. The result is a design process that is
disciplined, yet startling, combining discipline with adaptivity in a
way that arguably makes it the most well developed of all the adaptive
methodologies."
*Disciplinato*, piuttosto che *codificato* quindi, credo che potrebbe
andare bene: resta il fatto che a un livello superiore (potremmo
chiamarlo *meta* livello?:-), dato che essere disciplinati significa
comunque seguire delle *regole*, si puo' parlare di codifica delle
regole, e quindi di codifica della metodologia, seppure a un livello
superiore ;-))
>> a cogliere quegli aspetti essenziali
>>che rendono una metodologia *agile*, aspetti abbastanza facilmente
>>implementabili, attraverso l'adozione di una metodologia fatta su
>>*misura* ...
>Attenzione, Cockburn non prescrive un processo ma (cito) "a supplement to existing
>methods":
Infatti io ho parlato a proposito di metodologia fatta su *misura*,
ovvero, implicitamente, di una metodologia che non esiste, ovvero che
deve essere inventata, al contrario di quella di XP ;-)
>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)).
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
Michele Bendazzoli
wrote:
>>Su questo punto vorrei aggiungere qualcosa: in realta' credo che
>>l'approccio puro a XP...
>Non esiste l'approccio "puro" a XP, XP e' un metodo flessibile, non rigido. Nessuno vieta
>di fare diagrammi, documentazione, quello che ti pare se ti serve o se te lo chiede il
>cliente.
Essere puri non significa necessariamente essere integralisti. San
Francesco era un gran Santo, ma non mi risulta che fosse un *rigido*
integralista :-))
>>... 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'.
>In XP la lingua franca e' il codice, che tutti conoscono (vedi PairProgramming,
>CollectiveOwnership, etc.)
E io cosa ho detto scusa?
>>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)...
>Attenzione, non funziona cosi. I test sono scritti incrementalmente, e ogni nuovo test
>porta in genere a costruire nuovo codice che implementa il test.
Non ho mai detto il contrario. E' ovvio che se l'analisi e la
progettazione sono incrementali, saranno incrementali anche 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.
>Il punto non e' UML: il punto e' il design anticipato, il (B)DUF ((Big) Design Up Front)
>che porta con se innata complessita, pagando un alto prezzo cercando di anticipare
>cambiamenti che e' possibile non si verifichino mai.
Il punto e' che l'UML per definizione *anticipa* l'analisi rispetto al
codice. Era proprio il punto che cercavo di spiegare: con l'UML si
perde la possibilita' di verificare immediatamente con dei test
(incrementali;-) i progressivi raffinamenti nell'analisi e nella
progettazione.
>Il motivo e' che UML e' stato disegnato da anticipazionisti, persone convinte che
>realizzare un sistema software sia analogo a realizzare un ponte su un fiume.
Finalmente ci troviamo d'accordo: se ti scorri quanto ho scritto
vedrai che ho perfino citato l'esempio dell'ingegneria civile, che
divide nettamente il *progetto* dalla *costruzione*, come esempio di
approccio tradizionalista ;-)
>>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...
>Non c'e' contraddizione fra UML e XP: XP puo' usare UML, ma non in modo anticipazionista.
Se proprio vogliamo giocare con le parole, e perdere il senso di cio'
che dice l'altro interlocutore, ti ripeto che l'UML anticipa *per
definizione* l'analisi all'implementazione ;-)
[...]
>Si, presentato a XP200. L'ho letto un po' di tempo fa ma adesso mi rinfresco...
>Mah... come gia' allora la prima fase mi da un po' fastidio: "XP... has been
>criticised.... leaving behind design". In XP si fa design, un sacco! Bisogna conoscere
>*perfettamente* i principi di design, solo che li si applica _dopo_, non in modo
>anticipato.
>
>Okay, comunque adesso mi sforzo di rileggerlo con attenzione e poi commento.
Vedrai che non solo non criticano l'XP, ma lo pongono come metodologia
di riferimento ... solo potenziata dalla possibilita' di fare un uso
pervasivo dell'UML ;-)
>>Sembrerebbe la chiusura del cerchio ... speriamo :-)
>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
Michele Bendazzoli
wrote:
>On Thu, 09 Aug 2001 08:42:21 GMT, micky...@galactica.it (Michele Bendazzoli) wrote:
>
>Ciao,
>
> prima di tutto il mio team usa XP, tutte e 12 le pratiche, quindi penso di potere dare
>il mio contributo a questa discussione molto interessante! Yep! Finalmente!
Credo anch'io lo sia, peraltro sto valutando in questo periodo come
devo organizzare un progetto, e credo che, con gli opportuni
aggiustamenti, andro' verso questa direzione anch'io.
>Comunque se ti
>interessa XP, e in special modo in Italia, iscriviti alla lista su yahoogroups gemella di
>quella americana, ovvero http://groups.yahoo.com/group/extremeprogramming-it/
Ti ringrazio per il link.
>>Da questa premessa sembrerebbe ovvio che i sostenitori dell'XP
>Dire che gli svluppatori XP non vogliono saperne di UML e' fortissimo!
Se noti bene, vedrai che ho *consapevolmente* usato il congiuntivo :-)
>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?
Io credo che non esista una soluzione universale al problema dello
sviluppo del software: e' vero che l'analogia "costruire un ponte" e
"sviluppare un progetto software" e' profondamente sbagliata, e quindi
sono anch'io convinto che l'approccio adattativo sia in genere
corretto, cionondimeno, sono anche convinto che in alcuni casi non
c'e' adattamento che tenga: il problema da risolvere e' li' davanti,
e' bello grosso, difficile, e sperare di risolverlo un po' alla volta,
senza impegnarsi in un grosso sforzo di analisi, e' pressoche'
impossibile. Con questo non voglio dirti che l'analisi deve essere
esaustiva, o che possa prevedere tutto nei minimi dettagli, ma
certamente che abbia una profondita' sufficiente per risolvere a
grandi linee almeno lo scoglio piu' grosso, si', sono convinto che in
problemi *difficili* sia necessario. Che poi in genere questi casi
siano limitati, e che comunque sgrossato il problema maggiore sia
comunque utile proseguire in seguito con un approccio adattativo, sono
d'accordo con te.
Vuoi un esempio di un problema *difficile*? Eccoti accontentato:-))
Quando ho sviluppato nella mia tesi (mi perdonerai se te la cito ma e'
il problema piu' difficile che finora abbia dovuto risolvere:-) gli
algoritmi che consentono l'aggiornamento incrementale (ancora
incrementale !:-) di un program dependence graph durante una sessione
di editing, se avessi usato un approccio adattativo sarei ancora qui a
a scrivere codice ;-)
Dopo tre o quattro mesi di mesi di incubi e visioni invece me ne sono
uscito con le idee base per i tre algoritmi che mi servivano.
Se vuoi ti concedo pure che via via che sviluppavo le dimostrazioni di
correttezza e completezza (in pratica i miei *test*: sono stato un
Xper ante-literam:-) mi hanno dato un grosso aiuto nello stanare gli
errori dell'analisi e quindi lo spunto per correggere gli algoritmi (e
*semplificarli*, alla fine sono rimaste solo poche righe per ogni
algoritmo, a fronte di una trentina di pagine di dimostrazione!), ma
resta comunque indubitabile che prima di cominciare a raffinare e
"adattare" gli algoritmi in risposta agli innumerevoli errori che
trovavo mentre tentavo di dimostrarne la correttezza, ho dovuto prima
farmi marcire il cervello ...
Ecco io credo che l'analisi debba proseguire fino al momento in cui si
ha la "consapevole fiducia" di riuscire in qualche modo a risolvere il
problema che si ha davanti.
Se hai una grossa fiducia nelle tue possibilita' o comunque la
dimensione del problema da affrontare e' tale che te la senti comunque
di affrontarlo e risolverlo perche' hai gia' in mente, in nuce, una
possibile soluzione, allora io credo che sia corretto partire subito
con l'approccio adattativo ... evidentemente tu e kent Beck, avete una
smisurata fiducia nelle vostre capacita', e quindi potete utilizzare
l'approccio adattativo pressoche' in ogni caso :-))
>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...
Per il momento mi sento come un osservatore neutrale: quando avro'
tutti gli elementi che mi sembrano sufficienti per tirare una prima
concusione, vedro' di cominciare ad organizzarmi concretamente.
>Ultima osservazione tratta dai siti citati:
>"AM is an attitude, not a prescriptive process"
>"EM is a new software development process"
Faro' attenzione ;-)
ciao Michele
Bruno Bossola
>On Thu, 09 Aug 2001 14:13:37 GMT, bbos...@hotmail.com (Bruno Bossola)
>wrote:
>
>>XP non e' affatto "codificata", ma semplicemente tende alla specifica anche di un
>>processo. E nota che XP e' un metodo molto adattabile. Non esiste infatti il Metodo XP
>>(dovrei scriverlo tutto maiuscolo :-)), ma in genere ogni team sceglie di implementare le
>>pratiche nel modo piu' adatto per la propria realta'.
>
>Ok, vedo che passate ogni termine che uso sotto la lente di
>ingrandimento ... :-)
>Facciamo cosi' mi richiamo all'auctoritas cosi' mi levo d'impiccio:-)
>
>Cosi' Flower:
>
>"On this platform XP builds an evolutionary design process that relies
>on refactoring a simple base system with every iteration. All design
>is centered around the current iteration with no design done for
>anticipated future needs. The result is a design process that is
>disciplined, yet startling, combining discipline with adaptivity in a
>way that arguably makes it the most well developed of all the adaptive
>methodologies."
>
>*Disciplinato*, piuttosto che *codificato* quindi, credo che potrebbe
>andare bene: resta il fatto che a un livello superiore (potremmo
>chiamarlo *meta* livello?:-), dato che essere disciplinati significa
>comunque seguire delle *regole*, si puo' parlare di codifica delle
>regole, e quindi di codifica della metodologia, seppure a un livello
>superiore ;-))
>
Vedi, il problema e' che "codificato" indica una forma di rigidita' che in XP
semplicemente non esiste. XP e' un metodo (oltre che adattivo) anche adattabile, che deve
essere adeguato alla propria realta'
Colgo l'occasione per ribadire metodologia -> studio dei metodi :-)
A proposito, lo sai come lavora il team XP di Fowler? Cioe', il team in cui Fowler dice
che usa XP? E' diviso in due sotto-team: un team e' formato da programmatori diciamo
"sgualfi", che si occupano di buttare giu' codice che soddisfi i test, un altro team
invece rifattorizza solamente. Bello eh? E buonanotte al CollectiveCodeOwnership,
PairProgramming, ecc.ecc. Non so se adesso ha cambiato, sai, con il nuovo fanta-processo
(XM)...
>>> a cogliere quegli aspetti essenziali
>>>che rendono una metodologia *agile*, aspetti abbastanza facilmente
>>>implementabili, attraverso l'adozione di una metodologia fatta su
>>>*misura* ...
>
>>Attenzione, Cockburn non prescrive un processo ma (cito) "a supplement to existing
>>methods":
>
>Infatti io ho parlato a proposito di metodologia fatta su *misura*,
>ovvero, implicitamente, di una metodologia che non esiste, ovvero che
>deve essere inventata, al contrario di quella di XP ;-)
>
Forse devo chiarire un concetto. Un metodo e' definito mediante un processo ed una
notazione. Ad esempio, XP e' un metodo. UML e' una notazione. Waterfall e' un processo.
Cockburn non prescrive un metodo, tantomeno un processo, ma "un supplenmento ai metodi
esistenti". In sostanza, Cockburn prescrive una serie di pratiche supplementari rispetto
al metodo scelto.
Fowler sta cercando di vendere un nuovo metodo ed un nuovo processo sfruttando l'onda di
entusiasmo attorno a UML e completo di libri, tool, supporto, ecc.ecc. (come Rational sta
facendo con RUP, per intenderci)
Le due posizioni sono molto diverse.
>>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)).
>
>Cito ancora, in caso puoi scrivere a Fowler ;-)
>
(Guarda che Fowler non e' proprio la mia passione. Ti consiglio di conoscerlo
personalmente, puoi farlo alla prossima XP conference, e di farti una tua personale
opinione su di lui.)
Poi se parli di Cockburn sarebbe opportuno citassi lui stesso, non un'altra persona :-)
>"Cockburn's Crystal Family
>[snip]
>
>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 ;-)
>
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.
Bruno Bossola
>>Non esiste l'approccio "puro" a XP, XP e' un metodo flessibile, non rigido. Nessuno vieta
>>di fare diagrammi, documentazione, quello che ti pare se ti serve o se te lo chiede il
>>cliente.
>
>Essere puri non significa necessariamente essere integralisti. San
>Francesco era un gran Santo, ma non mi risulta che fosse un *rigido*
>integralista :-))
>
Infatti e' importante capire come XP sia flessibile, e non sia rigida. Questo e'
necessario che sia compreso, XP e' un processo che deve essere adattato alla propria
realta'.
>>In XP la lingua franca e' il codice, che tutti conoscono (vedi PairProgramming,
>>CollectiveOwnership, etc.)
>
>E io cosa ho detto scusa?
>
Sorry, non avevo capito :-D
>>>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)...
>
>>Attenzione, non funziona cosi. I test sono scritti incrementalmente, e ogni nuovo test
>>porta in genere a costruire nuovo codice che implementa il test.
>
>Non ho mai detto il contrario. E' ovvio che se l'analisi e la
>progettazione sono incrementali, saranno incrementali anche i test.
>
Uhm... hai letto l'articolo di cui ti ho fornito il link? L'incremento di funzionalita'
non avviene implementando macro-funzionalita ma avviene implementando micro-funzionalita.
Voglio dire, a mano a mano che si scrive il codice di una classe di test vengono aggiunte
funzionalita' alle classi testate che sono molto piccole. Il microciclo e' veramente
*molto* stretto: si parla di decine di minuti per un microciclo, non di ore o giorni.
Quando parliamo di test incrementali non parliamo dei test di accettazione (AT) scritti
dall'utente, ma dei test funzionali e unit-test (FT / UT) scritti dal programmatore.
>>>... 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.
>
>>Il punto non e' UML: il punto e' il design anticipato, il (B)DUF ((Big) Design Up Front)
>>che porta con se innata complessita, pagando un alto prezzo cercando di anticipare
>>cambiamenti che e' possibile non si verifichino mai.
>
>Il punto e' che l'UML per definizione *anticipa* l'analisi rispetto al
>codice. Era proprio il punto che cercavo di spiegare: con l'UML si
>perde la possibilita' di verificare immediatamente con dei test
>(incrementali;-) i progressivi raffinamenti nell'analisi e nella
>progettazione.
>
Secondo me non hai chiaro il concetto di test incrementale, almeno, non quello espresso da
XP. Ti consiglio di leggere l'articolo che ti ho passato. Non e' sufficiente fare le cose
un po' alla volta per essere incrementali. E il design anticipato per definizione anticipa
il cambiamento: "mettiamo un'interfaccia la' in modo che in futuro, se succede...". Hai
presente l'Open-Close Principle?
>>Il motivo e' che UML e' stato disegnato da anticipazionisti, persone convinte che
>>realizzare un sistema software sia analogo a realizzare un ponte su un fiume.
>
>Finalmente ci troviamo d'accordo: se ti scorri quanto ho scritto
>vedrai che ho perfino citato l'esempio dell'ingegneria civile, che
>divide nettamente il *progetto* dalla *costruzione*, come esempio di
>approccio tradizionalista ;-)
>
Okay, io lo vedo come un esempio negativo: come tu sai, non funziona cosi. Io, dopo un po'
di anni passati nello sviluppo di software, mi sono fatto delle idee che collimano molto
con quelle espresse da XP: abbracciare il cambiamento! L'ingengneria civile in questo non
e' che ci acchiappi molto.
>>>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...
>
>>Non c'e' contraddizione fra UML e XP: XP puo' usare UML, ma non in modo anticipazionista.
>
>Se proprio vogliamo giocare con le parole, e perdere il senso di cio'
>che dice l'altro interlocutore, ti ripeto che
>
Non voglio perdere il senso di niente ne' gioco con le parole, assolutamente,
semplicemente la penso diversamente da te. Vedi sotto.
>...l'UML anticipa *per definizione* l'analisi all'implementazione ;-)
No.
UML si puo' semplicemente utilizzare come ulteriore linguggio per dialogare, sia con in
cliente che all'interno del team. L'esempio sono gli sketch di collaboration diagram che
trovo a volte nei cestini, il deployment diagram che se mi giro vedo sulla lavagna. In
sostanza, in XP si usa UML, ma non per fare (B)DUF. Semplicemente, per spiegarsi. Di
nuovo, dai un'occhiata all'esempio del bowling di cui ti ho passato il link e guarda come
l'uso di UML in modo anticipato li avrebbe portati da una implementazione errata. Anzi, se
vuoi, leggi solo l'introduzione e prova a realizzare tu il sistema proposto usando il
metodo che vuoi: poi controlla a cosa sei arrivato.
>[...]
>>Si, presentato a XP200. L'ho letto un po' di tempo fa ma adesso mi rinfresco...
>>Mah... come gia' allora la prima fase mi da un po' fastidio: "XP... has been
>>criticised.... leaving behind design". In XP si fa design, un sacco! Bisogna conoscere
>>*perfettamente* i principi di design, solo che li si applica _dopo_, non in modo
>>anticipato.
>>
>>Okay, comunque adesso mi sforzo di rileggerlo con attenzione e poi commento.
>
>Vedrai che non solo non criticano l'XP, ma lo pongono come metodologia
>di riferimento ... solo potenziata dalla possibilita' di fare un uso
>pervasivo dell'UML ;-)
>
Vedi, quello che non va in cio' che propongono loro e' che cercano di rendere interattivi
di diagrammi, e tutto questo e' quasi comico per me. In OO cio' che interagisce sono gli
oggetto: sarebbe interessante un tool che avesse questo orientamento, e in giro qualche
progetto del genere c'e'. Se loro si sposteranno in quella direzione (ma non mi sembra sia
cosi) puo' darsi che raccolgano dei risultati. Sicuramente comunque fra i concetti
espressi nel paper e il metodo che cerca di vendere Fowler, di acqua ne passa parecchia.
>>>Sembrerebbe la chiusura del cerchio ... speriamo :-)
>>>
>>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 ;-)
>
Gia'... vorra' dire qualcosa :-)?
Bruno Bossola
>>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?
>
>Io credo che non esista una soluzione universale al problema dello
>sviluppo del software: e' vero che l'analogia "costruire un ponte" e
>"sviluppare un progetto software" e' profondamente sbagliata, e quindi
>sono anch'io convinto che l'approccio adattativo sia in genere
>corretto, cionondimeno, sono anche convinto che in alcuni casi non
>c'e' adattamento che tenga: il problema da risolvere e' li' davanti,
>e' bello grosso, difficile, e sperare di risolverlo un po' alla volta,
>senza impegnarsi in un grosso sforzo di analisi, e' pressoche'
>impossibile. Con questo non voglio dirti che l'analisi deve essere
>esaustiva, o che possa prevedere tutto nei minimi dettagli, ma
>certamente che abbia una profondita' sufficiente per risolvere a
>grandi linee almeno lo scoglio piu' grosso, si', sono convinto che in
>problemi *difficili* sia necessario. Che poi in genere questi casi
>siano limitati, e che comunque sgrossato il problema maggiore sia
>comunque utile proseguire in seguito con un approccio adattativo, sono
>d'accordo con te.
>
Secondo me ti sbagli :-)
Non e' facile utilizzare un approccio incrementale stretto nello sviluppo del software, e'
necessario conoscere molto ben OO ed avere fatto un bel po' di esperienza. Molte persone
ci provano, senza le dovute basi, e concludono che e' impossibile, non puo' funzionare.
>Vuoi un esempio di un problema *difficile*? Eccoti accontentato:-))
>Quando ho sviluppato nella mia tesi (mi perdonerai se te la cito ma e'
>il problema piu' difficile che finora abbia dovuto risolvere:-) gli
>algoritmi che consentono l'aggiornamento incrementale (ancora
>incrementale !:-) di un program dependence graph durante una sessione
>di editing, se avessi usato un approccio adattativo sarei ancora qui a
>a scrivere codice ;-)
>
E' possibile. Puo' darsi che se lo stesso problema lo avessi passato ad un team XP
esperto, te lo avrebbe risolto in qualche settimana.
>Dopo tre o quattro mesi di mesi di incubi e visioni invece me ne sono
>uscito con le idee base per i tre algoritmi che mi servivano.
>
Troppo tempo. Il cliente nel frattempo avrebbe cancellato il progetto. Il cliente vuole
vedere qualche risultato nel giro di un mese.
>Se vuoi ti concedo pure che via via che sviluppavo le dimostrazioni di
>correttezza e completezza (in pratica i miei *test*: sono stato un
>Xper ante-literam:-)...
>
Sorry, mi sa che siamo distanti sui test. Ti consiglio nuovamente di leggere l'articolo
che ti ho passato.
>...mi hanno dato un grosso aiuto nello stanare gli
>errori dell'analisi e quindi lo spunto per correggere gli algoritmi (e
>*semplificarli*, alla fine sono rimaste solo poche righe per ogni
>algoritmo, a fronte di una trentina di pagine di dimostrazione!), ma
>resta comunque indubitabile che prima di cominciare a raffinare e
>"adattare" gli algoritmi in risposta agli innumerevoli errori che
>trovavo mentre tentavo di dimostrarne la correttezza, ho dovuto prima
>farmi marcire il cervello ...
>
Scrivendo il codice dei test forse tu la stavi rifacendo l'analisi. E se avessi iniziato a
scrivere direttamente il codice di qualche test, anche semplice? E poi piano piano ne
avessi incrementato le funzionalita'? Per poi raffinarlo? In realta', cosa hai fatto
facendo l'analisi? Non hai fatto dei test nella tua mente? Prima semplici e poi +
complessi? Non hai cercato di identificare le ortogonalita' del problema?
>Ecco io credo che l'analisi debba proseguire fino al momento in cui si
>ha la "consapevole fiducia" di riuscire in qualche modo a risolvere il
>problema che si ha davanti.
>Se hai una grossa fiducia nelle tue possibilita' o comunque la
>dimensione del problema da affrontare e' tale che te la senti comunque
>di affrontarlo e risolverlo perche' hai gia' in mente, in nuce, una
>possibile soluzione, allora io credo che sia corretto partire subito
>con l'approccio adattativo ...
>
Il trucco e' che devi cercare di affrontare cose semplici, non complesse. Non devi cercare
di addentare il problema intero, ma devi arrivarci piano piano, partendo da situazioni
molto semplici. Quando decidi *cosa* testare, stai facendo implicitamente analisi. E a
mano a mano che scrivi nuovi test, stai facendo analisi, chiedendo conferme a te stesso se
avevi veramente capito.
Non e' facile.
Tutta l'ingegneria del software attuale e' basata sulla complessita' e sull'anticipazione.
Questo ti insegnano. Beh, bisogna rendersi conto che tutto cio' non e' necessario.
>... evidentemente tu e kent Beck....
>
Kent lo conosco di persona. La prima cosa che mi disse quando tentai di spiegargli il
problema cui lavoravo fu "non ho capito", un 3/4 volte. Poi me lo fece rispiegare. Poi mi
disse che stavo anticipando. Insomma, mi fece un culo cosi :-) Pero' e' una brava persona.
> ...avete una smisurata fiducia nelle vostre capacita'...
>
No. Uno dei principi di XP e' umilta'. E io ci ho messo un bel po' a capirlo: dopo 12 anni
che sviluppavo software, credevo di avere capito tutto di OOA, OOD, ecc. ecc.
Invece non avevo capito molto. E' dura da ammettere, ma come dice Francesco, il mio
mentor, "prima di riempire la tazza bisogna svuotarla.". Io ti consiglio di svuotare la
tazza.
> ...e quindi potete utilizzare l'approccio adattativo pressoche' in ogni caso :-))
>
Si, si puo' usare test-first incrementale in ogni caso.
>>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...
>
>Per il momento mi sento come un osservatore neutrale: quando avro'
>tutti gli elementi che mi sembrano sufficienti per tirare una prima
>concusione, vedro' di cominciare ad organizzarmi concretamente.
>
>>Ultima osservazione tratta dai siti citati:
>>"AM is an attitude, not a prescriptive process"
>>"EM is a new software development process"
>
>Faro' attenzione ;-)
>
Gia', perche' fra dare delle indicazioni e definire un nuovo processo, cercando di
venderlo, c'e' molta differenza.
Cristiano Sadun
>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
E' a questo che mi riferivo parlando di modo di usare UML. Con un tool
di roundtrip adeguato, usato consistentemente (il che e' la cosa
che non succede :-), non c'e' distanza tra modello e codice: il primo
e' un'astrazione rigorosa del secondo (cioe' ne' e' proprio un "modello",
tecnicamente parlando).
La contraddizione e' tra l'uso di UML pre- o post- produzione ('morto' :)
e UML *durante* la produzione ('vivo' :). UML o, intendimi, qualunque
linguaggio grafico che astragga da dettagli irrilevanti, che sia noto e
che abbia un supporto in tool appositi.
Mi spiego meglio, perche' in effetti non ho mai illustrato esattamente
cosa succede: tu sei seduto con un collega e stai progettando
un modulo. In ogni momento, dici cose tipo "okay, pare ci sia una classe
'cliente' in relazione con una classe 'ordine'". e butti giu' uno sketch
in codice. Ora, 'ste cose le puoi dire inefficientemente, in italiano,
e *poi* scrivere a mano il corrispondente codice; oppure puoi dirle
efficientemente e chiaramente, usando un (buon) tool di roundtrip:
disegni la classe, generi lo skeleton, riempi i prototipi, col minor
tempo possibile tra l'idea espressa e la realizzazione in codice.
Proseguendo nel lavoro, le idee possono cambiare, o se ne possono testare
di diverse: quindi aggiungi e togli associazioni, metodi e attributi, fai
refactoring, rinomini pezzi di codice e classi etc, apri un nuovo design
e fai il r/e dei pezzi del vecchio che hai gia' in mente, etc.
Chiaro che se non conosci UML o stai imparando, il secondo metodo sara'
inizialmente piu' lento. Idem se il tool non e' buono: un tool solo per
"disegnare" a me personalmente serve poco o punto: disegno piu'
velocemente a mano ;-). Lo sforzo di imparare e provare, imho, vale la
candela: io personalmente quando scrivo codice sono piu' efficiente cosi'
(a meno che non stia scrivendo piccole utility, nel qual caso il codice
e' prettamente procedurale e UML overkill).
Cio' che fa la differenza, nota, non e' ne' UML di per se, ne' il codice
di per se' - ma la capacita' del tool di tenere i due in sync e la
coerenza dello sviluppatore nello sfruttare tale capacita'.
>, 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'.
Il problema e' che, a meno di casi banali, *e'* difficile estrarre
dal codice il modello: e un sequence diagram (corretto e coerente
col codice) chiarisce una sequenza di esecuzione in molto meno
tempo che l'esame del corrispondente codice.
> 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 questo perche'? :-)
>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.
In effetti, il massimo vantaggio di UML (in quanto linguaggio grafico, e
rispetto ad altri linguaggi grafici anche migliori) e' proprio nel
fatto che rende la comunicazione piu' efficiente. Secondariamente,
nel fatto che - dati tool opportuni - aiuta a trasferire le cose
comunicate in codice in modo piu' robusto (e piu' efficiente).
>
>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.
Esattamente. Oggidi', esistono tool che si avvicinano parecchio a questo
ideale. Io sto abbandonando Rose e vedendo un po' cosa c'e' in giro.
E gia' con Rose (solo dopo aver provato e riprovato, purtroppo) ottengo
in genere piu' efficienza di produzione che scrivendo a mano.
(tra parentesi, e' interessante notare che Robert Martin era nel
team di sviluppo originale di Rose.. :-).
>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 ... ;-)
Esattamente. Ce ne sono pure altri. Il problema (con UML e linguaggi
analoghi) e' che questo modo d'uso di cui stiamo parlando e' nato,
come dire, in opposizione all'idea iniziale con cui il linguaggio e i
tool sono stati prodotti - che partivano appunto da una visione "statica"
del linguaggio di modellazione e del suo uso: di conseguenza gli
aspetti semantici di UML non sono stati inizialmente chiariti a
sufficienza da permettere l'esecuzione di un modello (la qual cosa
e' in corso di miglioramento - UML1.3 *ha* una semantica ben definita
per la maggior parte). Anche ragioni storiche, di potenza di calcolo,
rendevano l'idea di un modello "eseguibile" assolutamente impensabile
solo pochi anni fa.
>
>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.
Devo darci un'occhiata. ;-)
Michele Bendazzoli
>Vedi, il problema e' che "codificato" indica una forma di rigidita' che in XP
>semplicemente non esiste. XP e' un metodo (oltre che adattivo) anche adattabile, che deve
>essere adeguato alla propria realta'
Vedo che non hai mai studiato il teorema di incompletezza di Godel :-)
Pensa che egli e' riuscito a transcodificare l'intera aritmetica,
tanto che a due livelli di lettura di codifica diversi, gli *stessi*
segni, venivano interpretati in due teoremi che si contraddicevano
l'un con l'altro ... :-))
Ovviamente ho inteso il senso con cui stai precisando il senso da
assegnare al termine *codifica*, che connota in genere un certo senso
di rigidita', (come ho gia' precisato, *disciplina* sarebbe stato
sicuramente un termine piu' felice), ma permetti anche a me una volta
di fare le pulci a quel che dici ... :-))
>Colgo l'occasione per ribadire metodologia -> studio dei metodi :-)
In realta' metodologia ha piu' di un significato, fra i quali c'e'
anche quello di *metodo*.
Da garzanti online.
1 (filos.) dottrina del metodo; studio dei principi e delle regole che
permettono il conseguimento e lo sviluppo delle conoscenze in una
determinata disciplina
2 metodo: difettare, mancare di metodologia; le moderne metodologie
critiche.
Credo che XP sia da intendere piu' nel secondo significato che nel
primo.
>A proposito, lo sai come lavora il team XP di Fowler? Cioe', il team in cui Fowler dice
>che usa XP? E' diviso in due sotto-team: un team e' formato da programmatori diciamo
>"sgualfi", che si occupano di buttare giu' codice che soddisfi i test, un altro team
>invece rifattorizza solamente. Bello eh? E buonanotte al CollectiveCodeOwnership,
>PairProgramming, ecc.ecc. Non so se adesso ha cambiato, sai, con il nuovo fanta-processo
>(XM)...
Cosa ti dicevo: non segue la metodologia XP *pura* ... :-))
>>Infatti io ho parlato a proposito di metodologia fatta su *misura*,
>>ovvero, implicitamente, di una metodologia che non esiste, ovvero che
>>deve essere inventata, al contrario di quella di XP ;-)
>Forse devo chiarire un concetto. Un metodo e' definito mediante un processo ed una
>notazione. Ad esempio, XP e' un metodo. UML e' una notazione. Waterfall e' un processo.
>
>Cockburn non prescrive un metodo, tantomeno un processo, ma "un supplenmento ai metodi
>esistenti". In sostanza, Cockburn prescrive una serie di pratiche supplementari rispetto
>al metodo scelto.
>Fowler sta cercando di vendere un nuovo metodo ed un nuovo processo sfruttando l'onda di
>entusiasmo attorno a UML e completo di libri, tool, supporto, ecc.ecc. (come Rational sta
>facendo con RUP, per intenderci)
>Le due posizioni sono molto diverse.
Ovviamente hai ragione: ti confesso che mi sono rifatto a quanto ha
scritto Fowler su Coockburn, non tanto perche' consideri Fowler il
vate, ma per il semplice motivo che Coockburn non l'ho ancora letto
(anche se ho gia' scaricato il suo *.pdf "Agile Software Development"
e penso che lo leggero' a giorni), e quindi ho postato l'unico
materiale che indirettamente avevo a disposizione :-(
>>Cito ancora, in caso puoi scrivere a Fowler ;-)
>>
>(Guarda che Fowler non e' proprio la mia passione. Ti consiglio di conoscerlo
>personalmente, puoi farlo alla prossima XP conference, e di farti una tua personale
>opinione su di lui.)
>Poi se parli di Cockburn sarebbe opportuno citassi lui stesso, non un'altra persona :-)
Non appena lo avro' letto, correggero' il tiro, promesso :-)
>>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 ;-)
>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.
Ok, messaggio recepito, Fowler bisogna leggerlo con il beneficio
dell'inventario :-)
ciao, Michele
Michele Bendazzoli
wrote:
>>Non ho mai detto il contrario. E' ovvio che se l'analisi e la
>>progettazione sono incrementali, saranno incrementali anche i test.
>Uhm... hai letto l'articolo di cui ti ho fornito il link? L'incremento di funzionalita'
>non avviene implementando macro-funzionalita ma avviene implementando micro-funzionalita.
In realta' no: sto finendo proprio ora di leggere "extreme programming
explained" di Kent Beck (spero ne sarai contento:-), dopo di che
leggero' quello di Coockburn, e, se avanzo tempo, ti prometto che
leggo anche l'articolo per il quale mi hai fornito il link :-)
>Voglio dire, a mano a mano che si scrive il codice di una classe di test vengono aggiunte
>funzionalita' alle classi testate che sono molto piccole. Il microciclo e' veramente
>*molto* stretto: si parla di decine di minuti per un microciclo, non di ore o giorni.
>Quando parliamo di test incrementali non parliamo dei test di accettazione (AT) scritti
>dall'utente, ma dei test funzionali e unit-test (FT / UT) scritti dal programmatore.
Credo di aver capito cosa intendi: in realta' non vedo l'ora di
cominciare a mettere in pratica questa tecnica sul campo.
Devo dire infatti, che leggendo il libro di Beck sono rimasto
abbastanza stupefatto della similitudine del suo approccio con quello
che *naturalmente* si e' sviluppato all'interno del nostro team. Dal
lavorare in coppia, alla continua semplificazione e correzione del
codice esistente, ai cicli di release molto brevi, al
CollectiveCodeOwnership, devo dire che le analogie sono addirittura
sorprendenti.
L'aspetto principale che pero' ci manca ancora e' proprio quello dei
test, aspetto che sono convinto potra' essere molto interessante.
Devo anche aggiungere pero' che questo metodo fatto in casa, ci ha si'
consentito un discreto successo nel sistemare un programma *gia'
esistente*, ma devo ancora valutare le sue potenzialita' durante lo
sviluppo di un intero progetto, cosa che probabilmente accadra' a
breve, progetto che fra l'altro non corrisponde molto bene ai
requisiti indicati da Beck dato che e' chiavi in mano, e prevede in
anticipo, oltre al costo valutato in diversi mesi (lo so, non si
dovrebbe ma cosi' e' andata ...), l'intero set di funzionalita' da
sviluppare. E' per questo che sto guardandomi in giro in questo
periodo e, dopo avere recentemente scoperto l'esistenza di XP, come
fare eventualmente a gestire un tale progetto con una tale
metodologia.
>>Il punto e' che l'UML per definizione *anticipa* l'analisi rispetto al
>>codice. Era proprio il punto che cercavo di spiegare: con l'UML si
>>perde la possibilita' di verificare immediatamente con dei test
>>(incrementali;-) i progressivi raffinamenti nell'analisi e nella
>>progettazione.
>Secondo me non hai chiaro il concetto di test incrementale, almeno, non quello espresso da
>XP. Ti consiglio di leggere l'articolo che ti ho passato. Non e' sufficiente fare le cose
>un po' alla volta per essere incrementali. E il design anticipato per definizione anticipa
>il cambiamento: "mettiamo un'interfaccia la' in modo che in futuro, se succede...". Hai
>presente l'Open-Close Principle?
Ok, lo faro' non appena ne avro' il tempo.
>Okay, io lo vedo come un esempio negativo: come tu sai, non funziona cosi. Io, dopo un po'
>di anni passati nello sviluppo di software, mi sono fatto delle idee che collimano molto
>con quelle espresse da XP: abbracciare il cambiamento! L'ingengneria civile in questo non
>e' che ci acchiappi molto.
Infatti ;-)
>>Se proprio vogliamo giocare con le parole, e perdere il senso di cio'
>>che dice l'altro interlocutore, ti ripeto che
>Non voglio perdere il senso di niente ne' gioco con le parole, assolutamente,
>semplicemente la penso diversamente da te. Vedi sotto.
>>...l'UML anticipa *per definizione* l'analisi all'implementazione ;-)
>No.
>UML si puo' semplicemente utilizzare come ulteriore linguggio per dialogare, sia con in
>cliente che all'interno del team. L'esempio sono gli sketch di collaboration diagram che
>trovo a volte nei cestini, il deployment diagram che se mi giro vedo sulla lavagna. In
>sostanza, in XP si usa UML, ma non per fare (B)DUF. Semplicemente, per spiegarsi. Di
>nuovo, dai un'occhiata all'esempio del bowling di cui ti ho passato il link e guarda come
>l'uso di UML in modo anticipato li avrebbe portati da una implementazione errata. Anzi, se
>vuoi, leggi solo l'introduzione e prova a realizzare tu il sistema proposto usando il
>metodo che vuoi: poi controlla a cosa sei arrivato.
Quello che scherzosamente volevo farti notare e' che in realta' stiamo
ognuno cercando di convincere l'altro di una cosa di cui entrambi
siamo convinti: quanto parlo di *contraddizione* tra UML e XP non
intendo dire altro che quello che tu stesso hai ribadito:
"Il motivo e' che UML e' stato disegnato da anticipazionisti, persone
convinte che realizzare un sistema software sia analogo a realizzare
un ponte su un fiume."
E' chiaro poi che uno puo' piegare l'UML ai propri scopi, e quindi,
come ho anche gia' ribadito, la contraddizione e' in realta' piu'
apparente che reale.
>Vedi, quello che non va in cio' che propongono loro e' che cercano di rendere interattivi
>di diagrammi, e tutto questo e' quasi comico per me. In OO cio' che interagisce sono gli
>oggetto: sarebbe interessante un tool che avesse questo orientamento, e in giro qualche
>progetto del genere c'e'. Se loro si sposteranno in quella direzione (ma non mi sembra sia
>cosi) puo' darsi che raccolgano dei risultati. Sicuramente comunque fra i concetti
>espressi nel paper e il metodo che cerca di vendere Fowler, di acqua ne passa parecchia.
Questa mi pare una obiezione interessante, ma non so fino a che punto
giustificata. Quoto:
"[...]
To be able to simulate and try out a single diagram is nice. But each
diagram in UML has a certain role in the modeling process - they
should be used collectively.
The Class or static structure diagram provides architectural
information gatherd from other diagrams. A class contributes to the
system's behaviour in the sense that it provides access methods for
attributes and associations.
Toghether, state and activity diagrams specify the dinamic behaviour
of a system. We assume that a state machine models the state of a
single object. It can be seen as a model of the life-cycle of an
object or as the protocol to use an object. Events are mapped to
methods of the corresponding class. Activity diagrams are used for
modeling the finegraded steps of a single method. [...] "
Quindi esiste comunque una relazione tra la struttura delle classi e
la simulazione dei diagrammi dinamici.
Ma, se non ho capito male c'e' di piu' e di meglio:
"Since all annotations in the diagrams are in java, messages can also
be sent to real Java objects. The UML Virtual Machine contain a Java
parser, so that the incriptions can be checked for syntactical
correctness. Method call to Java objects are invoked using the
reflection mechanism. A simple example is the call Syetm.out.println()
at the entry of a state. A more sophisticated example is the creation
of a graphical user interface that can interact with the simulated
system. Similary, diagram instance are represented by java wrapper
objects that can be called from usual code.
The combination of these two mechanisms eliminates the difference
between modelled and coded objects. An object can first be modelled
graphically and later be implememnted in Java. It can be used for
execution in both cases. Thus a smooth transition from design to code
is made possible."
Applicato all'XP tutto cio consente ad esempio di
1) Testare i modelli attraverso i modelli: ad esempio un sequence
diagram puo' testare una diagramma degli stati.
2) Testare modelli attraverso il codice. I diagrammi possono essere
utilizzati da classi java regolari. In questo modo i test, ad esempio
un testcase scritto in java che dipende da Junit, puo' essere
utilizzato per testare un (insieme di) state machine.
3) Testare il codice attraverso i modelli. L'interazione tra il codice
a il modello lavora infatti in entrambe le direzioni, cosi' che una
classe puo' essere testata per esempio da un sequence diagram.
4) Combinazione a piacere di tutti e tre i casi precedenti.
Non so a te, ma a me tutto cio' appare abbastanza interessante. Certo
che vorrei provare a mettere le mani su qualcosa e fare dei test :-))
prima di dare un giudizio definitivo sulla praticabilita' ed
efficiacia di un tale approccio ... :-)
>Gia'... vorra' dire qualcosa :-)?
Che "ci stiamo attrezzando per i miracoli"? :-)
ciao, Michele
Michele Bendazzoli
wrote:
>> 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 questo perche'? :-)
Perche' non sono utilizzati gli strumenti ai quali hai fatto
riferimento :-)
Se noti infatti sto ancora parlando *nell'ipotesi* che la distanza tra
diagramma UML e codice sia elevata. E' ovvio che queste deduzioni
cadono non appena cade la barriera che divide il modello dal codice
..
>Esattamente. Oggidi', esistono tool che si avvicinano parecchio a questo
>ideale. Io sto abbandonando Rose e vedendo un po' cosa c'e' in giro.
Fammi sapere perche' sto anch'io guardandomi in giro con attenzione.
La mia impressione su Rose, per quanto molto superficiale dato che
1) Non conoscevo ancora a sufficienza l'UML
2) Non avevo molto tempo e risorse da impiegare
e' stata che esso non solo richiedesse un grosso sforzo iniziale di
apprendimento, ma che ti vincolasse notevolmente a tutta una serie di
tecnolgie e pratiche "alla Rose" che rendono poi difficile un
eventuale switch di strumento. Insomma devo dire che mi ha un po'
spaventato, non fino a che punto in modo giustificato.
>>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'UML, 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 ... ;-)
>Esattamente. Ce ne sono pure altri.
Non so gli altri (utenti intendo), ma io sarei molto interessato a
sapere a conoscere le tue opinioni e i giudizi su questi strumenti ...
:-)
>>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.
>
>Devo darci un'occhiata. ;-)
Fammi sapere cosa ne pensi.
ciao, Michele
Michele Bendazzoli
wrote:
>Secondo me ti sbagli :-)
>Non e' facile utilizzare un approccio incrementale stretto nello sviluppo del software, e'
>necessario conoscere molto ben OO ed avere fatto un bel po' di esperienza. Molte persone
>ci provano, senza le dovute basi, e concludono che e' impossibile, non puo' funzionare.
Guarda, devo dire che ripensando all'esempio personale che poi ti
avevo riportato, mi sono accorto che in realta', l'approccio
adattativo aveva svolto un ruolo piu' importante di quanto non mi
avessi immaginato. Devo anche riconoscere che i progressi piu' vistosi
nel mio lavoro, ho cominciato a farli proprio quando ho iniziato a
cercare di dimostrare che gli algoritmi erano corretti, ossia in
analogia a quanto affermato dall'XP, a quando ho cominciato in pratica
a testarli. Per quanto possa sembrare strano infatti sono convinto che
esista una relazione pressoche' biunivoca tra lo sviluppo di una
dimostrazione matematica, e quella di un programma, tanto che un lemma
potrebbe essere descritto come una specie di subroutine ... del
programma principale ... il teorema :-)
L'analogia e' stanto spinta che una volta che mi sono reso conto della
sua esistenza, ho capito quanti errori di impostazione ho compiuto nel
loro sviluppo, errori dovuti a una cattiva applicazione dei principi
dell'ingegneria del software ... tipo ad esempio ripetere piu' volte
lo stesso tipo di dimostrazione senza codificarla in un lemma, e
quindi senza evitare la duplicazione ... del *codice* :-))
In sostanza, per ritornare alla tua obiezione, non so fino a che punto
devo darti ragione: la cosa certa e' che piu' vado avanti e' piu' noto
le possibilita' offerte da un tale approccio, seppure utilizzato in
modo inconsapevole.
>E' possibile. Puo' darsi che se lo stesso problema lo avessi passato ad un team XP
>esperto, te lo avrebbe risolto in qualche settimana.
Puo' darsi :-)
>>Dopo tre o quattro mesi di mesi di incubi e visioni invece me ne sono
>>uscito con le idee base per i tre algoritmi che mi servivano.
>Troppo tempo. Il cliente nel frattempo avrebbe cancellato il progetto. Il cliente vuole
>vedere qualche risultato nel giro di un mese.
In realta' sono passati piu' di cinque anni prima che un certo tale,
in Canada mi pare (se vuoi ti posto il link del paper), sia riuscito a
fare qualcosa di equivalente: chissa' forse se invece che in Italia
avessi fatto quella tesi da qualche altra parte, almeno un cane che si
prendesse la briga di verificare l'utilita' di un lavoro durato un
anno intero, lo avrei trovato. Cosi' non fu :-(
>>Se vuoi ti concedo pure che via via che sviluppavo le dimostrazioni di
>>correttezza e completezza (in pratica i miei *test*: sono stato un
>>Xper ante-literam:-)...
>Sorry, mi sa che siamo distanti sui test. Ti consiglio nuovamente di leggere l'articolo
>che ti ho passato.
Lo leggero', ormai te l'ho promesso, ma sono *quasi* sicuro di non
sbagliare a vedere una analogia tra i due processi: vedi sopra (ps: e
sotto:).
>Scrivendo il codice dei test forse tu la stavi rifacendo l'analisi. E se avessi iniziato a
>scrivere direttamente il codice di qualche test, anche semplice?
E quello che sto cercando di dirti: in realta' le mie dimostrazioni
non erano altro che lo sviluppo di tutti i casi possibili per
verificare (testare?) a mano se l'algoritmo funzionava come avrebbe
dovuto oppure no. La cosa veramente sorprendente e' che trovare un
errore serviva anche per trovare lo spunto per la soluzione, che
veniva quindi implementata nell'algoritmo (magari attraverso drastici
tagli e/o rifattorizzazioni) e quindi nuovamente testata. Ora non so
cosa trovero' scritto in quel link, ma non credo che questa analogia
possa essere una semplice coincidenza ...
>E poi piano piano ne
>avessi incrementato le funzionalita'? Per poi raffinarlo? In realta', cosa hai fatto
>facendo l'analisi? Non hai fatto dei test nella tua mente? Prima semplici e poi +
>complessi? Non hai cercato di identificare le ortogonalita' del problema?
A questo non so risponderti: diciamo che avevo bisogno di costruirmi
un modello mentale delle strutture su cui sono andato poi a operare,
ossia quelle del PDG (il program dependence graph) e la simmetrica
struttura dell'albero dei postdominatori (ossia quello che rappresenta
i vincoli di sequenzialita' tra le varie istruzioni di un programma).
Solo quando ho avuto chiaro la relazioni tra le due strutture e il
metodo (non incrementale) di costruzione del PDG ho capito in che modo
una modifica del programma potesse riflettersi nell'aggiornamento
delle due strutture. Una volta chiarito cio' (la chiamiamo fase di
analisi?), produrre un algoritmo che implementasse tali modifiche non
e' stato molto difficile. Ripeto ad ogni modo che non so fino a che
punto le idee mi si sono chiarite attraverso i "test", oppure
attraverso qualche altro strano modo di ragionare.
>Il trucco e' che devi cercare di affrontare cose semplici, non complesse. Non devi cercare
>di addentare il problema intero, ma devi arrivarci piano piano, partendo da situazioni
>molto semplici. Quando decidi *cosa* testare, stai facendo implicitamente analisi. E a
>mano a mano che scrivi nuovi test, stai facendo analisi, chiedendo conferme a te stesso se
>avevi veramente capito.
Credo anch'io sia cosi'. Non so pero' se sia l'unico modo o comunque
quello piu' produttivo per farlo.
>Non e' facile.
>Tutta l'ingegneria del software attuale e' basata sulla complessita' e sull'anticipazione.
>Questo ti insegnano. Beh, bisogna rendersi conto che tutto cio' non e' necessario.
Su questo hai ragione: mi ricordo ancora il famoso grafico sulla
lavagna e sulla necessita' di investire il piu' possibile nella prima
fase (analisi e progetto), per potere passare, in modo *meccanico* e
quasi *definitivo*, alla fase di implementazione ...!
>Kent lo conosco di persona. La prima cosa che mi disse quando tentai di spiegargli il
>problema cui lavoravo fu "non ho capito", un 3/4 volte. Poi me lo fece rispiegare. Poi mi
>disse che stavo anticipando. Insomma, mi fece un culo cosi :-) Pero' e' una brava persona.
Da quel che ho letto finora sul suo libro, sono convinto che sia un
personaggio davvero notevole.
>> ...avete una smisurata fiducia nelle vostre capacita'...
>No. Uno dei principi di XP e' umilta'. E io ci ho messo un bel po' a capirlo: dopo 12 anni
>che sviluppavo software, credevo di avere capito tutto di OOA, OOD, ecc. ecc.
>Invece non avevo capito molto. E' dura da ammettere, ma come dice Francesco, il mio
>mentor, "prima di riempire la tazza bisogna svuotarla.". Io ti consiglio di svuotare la
>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
Cristiano Sadun
>Perche' non sono utilizzati gli strumenti ai quali hai fatto
>riferimento :-)
>Se noti infatti sto ancora parlando *nell'ipotesi* che la distanza tra
>diagramma UML e codice sia elevata. E' ovvio che queste deduzioni
>cadono non appena cade la barriera che divide il modello dal codice
Ah okay, pensavo ti riferissi ad UML di per se'. (ehm - scusa se appaio
brusco ma sto scrivendo molto di fretta, come tecnica di rilassamento ;-)
mentre stiamo lavorando ad un problema di performance che deve essere
risolto in due giorni.. :)
>Fammi sapere perche' sto anch'io guardandomi in giro con attenzione.
Ne ho visti un po' (se ho tempo mettero' in rete una survey) e la mia
shortlist e' Togheter 5 e StructureBuilder (ex VisualCafe' - ma devo
ancora provarlo, ne ho solo visto una demo al BEAWorld a Monaco).
ObjectDomain appare bello, ma ci sono degli errori nell'implementazione
di UML (tipo le association class).
>La mia impressione su Rose, per quanto molto superficiale dato che
>1) Non conoscevo ancora a sufficienza l'UML
>2) Non avevo molto tempo e risorse da impiegare
>
>e' stata che esso non solo richiedesse un grosso sforzo iniziale di
>apprendimento,
Si'.
>ma che ti vincolasse notevolmente a tutta una serie di
>tecnolgie e pratiche "alla Rose" che rendono poi difficile un
>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.
Bruno Bossola
>
>>Vedi, il problema e' che "codificato" indica una forma di rigidita' che in XP
>>semplicemente non esiste. XP e' un metodo (oltre che adattivo) anche adattabile, che deve
>>essere adeguato alla propria realta'
>
>Vedo che non hai mai studiato il teorema di incompletezza di Godel :-)
>Pensa che egli e' riuscito a transcodificare l'intera aritmetica,
>tanto che a due livelli di lettura di codifica diversi, gli *stessi*
>segni, venivano interpretati in due teoremi che si contraddicevano
>l'un con l'altro ... :-))
>
>Ovviamente ho inteso il senso con cui stai precisando il senso da
>assegnare al termine *codifica*, che connota in genere un certo senso
>di rigidita', (come ho gia' precisato, *disciplina* sarebbe stato
>sicuramente un termine piu' felice), ma permetti anche a me una volta
>di fare le pulci a quel che dici ... :-))
>
Okay, disciplina va benissimo, non e' questo il punto. Il punto e' che XP e' un metodo
(oltre che adattivo) anche adattabile, che deve essere adeguato alla propria realta'.
Non e' una soluzione "pronta all'uso".
>>Colgo l'occasione per ribadire metodologia -> studio dei metodi :-)
>
>In realta' metodologia ha piu' di un significato, fra i quali c'e'
>anche quello di *metodo*.
>
>Da garzanti online.
>1 (filos.) dottrina del metodo; studio dei principi e delle regole che
>permettono il conseguimento e lo sviluppo delle conoscenze in una
>determinata disciplina
>2 metodo: difettare, mancare di metodologia; le moderne metodologie
>critiche.
>
>Credo che XP sia da intendere piu' nel secondo significato che nel
>primo.
>
Si, XP e' un metodo, non una metodologia.
Comunque, parlando della lingua italiana, nel garzanti non a caso la prima definizione e'
quella di studio dei metodi, e se conosci il latino sicuramente puoi capirne il perche'.
Io ti consiglio di usare sempre "metodo" e di fare notare a quelli che usano
esageratamente metodologia (non e' il tuo caso, comunque :-D) che stanno semplicemente
sbagliando: gli insinui il tarlo del dubbio :-)
>>A proposito, lo sai come lavora il team XP di Fowler? Cioe', il team in cui Fowler dice
>>che usa XP? E' diviso in due sotto-team: un team e' formato da programmatori diciamo
>>"sgualfi", che si occupano di buttare giu' codice che soddisfi i test, un altro team
>>invece rifattorizza solamente. Bello eh? E buonanotte al CollectiveCodeOwnership,
>>PairProgramming, ecc.ecc. Non so se adesso ha cambiato, sai, con il nuovo fanta-processo
>>(XM)...
>
>Cosa ti dicevo: non segue la metodologia XP *pura* ... :-))
>
Non segue proprio XP. Delle 12 pratiche che dovrebbe implementare, il suo metodo ne
realizza molte meno. Per fare XP devi implementare tutte le pratiche (e' questo che
intendi per "puro"?) se implementi solo quelle che ti fanno comodo a te o che ti piacciono
di piu', e altre semplicemente non le consideri allora non stai facendo XP.
Comunque se intendi quello con XP pura sono d'accordo: XP si fa solo se il tuo metodo
implementa tutte e 12 le pratiche.
>...non tanto perche' consideri Fowler il vate...
E fai bene :-)
>Ok, messaggio recepito, Fowler bisogna leggerlo con il beneficio
>dell'inventario :-)
>
Gia' :-)
Bruno Bossola
>...sto finendo proprio ora di leggere "extreme programming
>explained" di Kent Beck (spero ne sarai contento:-), dopo di che
>leggero' quello di Coockburn, e, se avanzo tempo, ti prometto che
>leggo anche l'articolo per il quale mi hai fornito il link :-)
>
Ottimo! Se vuoi comunque una buona bibliografia per XP vai a questo sito:
http://www.xplabs.com/eng/contents/bookshop/home.html
>L'aspetto principale che pero' ci manca ancora e' proprio quello dei
>test, aspetto che sono convinto potra' essere molto interessante.
>
Prima di iniziare il tuo progetto ti consiglio vivissimamente di leggerti l'articolo che
ti ho mandato, che parla proprio di test-first incrementale:
http://www.objectmentor.com/publications/xpepisode.htm
Leggilo, leggilo!
>Devo anche aggiungere pero' che questo metodo fatto in casa, ci ha si'
>consentito un discreto successo nel sistemare un programma *gia'
>esistente*, ma devo ancora valutare le sue potenzialita' durante lo
>sviluppo di un intero progetto, cosa che probabilmente accadra' a
>breve, progetto che fra l'altro non corrisponde molto bene ai
>requisiti indicati da Beck dato che e' chiavi in mano, e prevede in
>anticipo, oltre al costo valutato in diversi mesi (lo so, non si
>dovrebbe ma cosi' e' andata ...), l'intero set di funzionalita' da
>sviluppare. E' per questo che sto guardandomi in giro in questo
>periodo e, dopo avere recentemente scoperto l'esistenza di XP, come
>fare eventualmente a gestire un tale progetto con una tale
>metodologia.
>
Nell'ultimo capitolo di XP explained trovi una sintetica spiegazione di come affrontare
questo tipo di progetto. Io e' da un po' di tempo che non lavoro piu' chiavi in mano: per
quanto riguarda la mia esperienza nella gestione di questo tipo di progetti ti consiglio
di istituire al giorno 0 un "giornale delle modifiche" sul quale riporti giorno dopo
giorno le modifiche funzionali richieste dal cliente, e che il cliente approva. Io cosi'
mi sono sempre trovato abbastanza bene, perche' ad ogni mese, durante le review, potevo
ricordare al cliente perche' eravamo in ritardo :-) Se invece il manuale qualita' della
tua azienda prevede gia' un documento del genere ancora meglio.
>>Secondo me non hai chiaro il concetto di test incrementale, almeno, non quello espresso da
>>Ti consiglio di leggere l'articolo che ti ho passato...
>
>Ok, lo faro' non appena ne avro' il tempo.
>
Leggilo, leggilo :-D
>>>...l'UML anticipa *per definizione* l'analisi all'implementazione ;-)
>
>>No.
>>UML si puo' semplicemente utilizzare come ulteriore linguggio per dialogare, sia con in
>>cliente che all'interno del team. L'esempio sono gli sketch di collaboration diagram che
>>trovo a volte nei cestini, il deployment diagram che se mi giro vedo sulla lavagna. In
>>sostanza, in XP si usa UML, ma non per fare (B)DUF. Semplicemente, per spiegarsi. Di
>>nuovo, dai un'occhiata all'esempio del bowling di cui ti ho passato il link e guarda come
>>l'uso di UML in modo anticipato li avrebbe portati da una implementazione errata. Anzi, se
>>vuoi, leggi solo l'introduzione e prova a realizzare tu il sistema proposto usando il
>>metodo che vuoi: poi controlla a cosa sei arrivato.
>
>Quello che scherzosamente volevo farti notare e' che in realta' stiamo
>ognuno cercando di convincere l'altro di una cosa di cui entrambi
>siamo convinti: quanto parlo di *contraddizione* tra UML e XP non
>intendo dire altro che quello che tu stesso hai ribadito:
>
>"Il motivo e' che UML e' stato disegnato da anticipazionisti, persone
>convinte che realizzare un sistema software sia analogo a realizzare
>un ponte su un fiume."
>
>E' chiaro poi che uno puo' piegare l'UML ai propri scopi, e quindi,
>come ho anche gia' ribadito, la contraddizione e' in realta' piu'
>apparente che reale.
>
Okay, ho capito.
>>Vedi, quello che non va in cio' che propongono loro e' che cercano di rendere interattivi
>>di diagrammi, e tutto questo e' quasi comico per me. In OO cio' che interagisce sono gli
>>oggetto: sarebbe interessante un tool che avesse questo orientamento, e in giro qualche
>>progetto del genere c'e'. Se loro si sposteranno in quella direzione (ma non mi sembra sia
>>cosi) puo' darsi che raccolgano dei risultati. Sicuramente comunque fra i concetti
>>espressi nel paper e il metodo che cerca di vendere Fowler, di acqua ne passa parecchia.
>
>Questa mi pare una obiezione interessante, ma non so fino a che punto
>giustificata.
>
Qui la discussione sarebbe molto lunga, e gia' ora siamo parecchio OT. Comunque anche qui
e' una questione di approccio. Tanto per buttare un sasso ti posso dire che OO *non* e' un
metodo per modellare la realta'. Ti risulta?
>"[...]
>To be able to simulate and try out a single diagram is nice. But each
>diagram in UML has a certain role in the modeling process - they
>should be used collectively.
> The Class or static structure diagram provides architectural
>information gatherd from other diagrams. A class contributes to the
>system's behaviour in the sense that it provides access methods for
>attributes and associations.
> Toghether, state and activity diagrams specify the dinamic behaviour
>of a system. We assume that a state machine models the state of a
>single object. It can be seen as a model of the life-cycle of an
>object or as the protocol to use an object. Events are mapped to
>methods of the corresponding class. Activity diagrams are used for
>modeling the finegraded steps of a single method. [...] "
>
>Quindi esiste comunque una relazione tra la struttura delle classi e
>la simulazione dei diagrammi dinamici.
>
Ma secondo te quali potrebbero essere i diagrammi piu' importanti nel mondo OO? E perche'?
>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).
Bruno Bossola
>[mega-snip]
>...Lo leggero', ormai te l'ho promesso...
>
Dai, ti vedo gia' abbandonare la strada oscura dell'anticipazione e prendere la limpida
via del test firs incrementale :-)
>In realta' sono passati piu' di cinque anni prima che un certo tale,
>in Canada mi pare (se vuoi ti posto il link del paper), sia riuscito a
>fare qualcosa di equivalente: chissa' forse se invece che in Italia
>avessi fatto quella tesi da qualche altra parte, almeno un cane che si
>prendesse la briga di verificare l'utilita' di un lavoro durato un
>anno intero, lo avrei trovato. Cosi' non fu :-(
>
Hey, complimenti!
>>Tutta l'ingegneria del software attuale e' basata sulla complessita' e sull'anticipazione.
>>Questo ti insegnano. Beh, bisogna rendersi conto che tutto cio' non e' necessario.
>
>Su questo hai ragione: mi ricordo ancora il famoso grafico sulla
>lavagna e sulla necessita' di investire il piu' possibile nella prima
>fase (analisi e progetto), per potere passare, in modo *meccanico* e
>quasi *definitivo*, alla fase di implementazione ...!
>
Eh, il caro vecchio Bohem :-)
>>No. Uno dei principi di XP e' umilta'. E io ci ho messo un bel po' a capirlo: dopo 12 anni
>>che sviluppavo software, credevo di avere capito tutto di OOA, OOD, ecc. ecc.
>>Invece non avevo capito molto. E' dura da ammettere, ma come dice Francesco, il mio
>>mentor, "prima di riempire la tazza bisogna svuotarla.". Io ti consiglio di svuotare la
>>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* :-))
>
Vedrai che dovrai svuotarla, e prima lo fai meglio e'. In bocca al lupo!
Michele Bendazzoli
wrote:
>Non segue proprio XP. Delle 12 pratiche che dovrebbe implementare, il suo metodo ne
>realizza molte meno. Per fare XP devi implementare tutte le pratiche (e' questo che
>intendi per "puro"?) se implementi solo quelle che ti fanno comodo a te o che ti piacciono
>di piu', e altre semplicemente non le consideri allora non stai facendo XP.
>
>Comunque se intendi quello con XP pura sono d'accordo: XP si fa solo se il tuo metodo
>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
Michele Bendazzoli
wrote:
>>L'aspetto principale che pero' ci manca ancora e' proprio quello dei
>>test, aspetto che sono convinto potra' essere molto interessante.
>Prima di iniziare il tuo progetto ti consiglio vivissimamente di leggerti l'articolo che
>ti ho mandato, che parla proprio di test-first incrementale:
>http://www.objectmentor.com/publications/xpepisode.htm
>Leggilo, leggilo!
Ho finito proprio adesso il libro, e ho deciso, nel piu' puro stile
adattativo, di leggere subito quell'articolo ;-)
>Nell'ultimo capitolo di XP explained trovi una sintetica spiegazione di come affrontare
>questo tipo di progetto. Io e' da un po' di tempo che non lavoro piu' chiavi in mano: per
>quanto riguarda la mia esperienza nella gestione di questo tipo di progetti ti consiglio
>di istituire al giorno 0 un "giornale delle modifiche" sul quale riporti giorno dopo
>giorno le modifiche funzionali richieste dal cliente, e che il cliente approva. Io cosi'
>mi sono sempre trovato abbastanza bene, perche' ad ogni mese, durante le review, potevo
>ricordare al cliente perche' eravamo in ritardo :-) Se invece il manuale qualita' della
>tua azienda prevede gia' un documento del genere ancora meglio.
Grazie per il consiglio.
>>Questa mi pare una obiezione interessante, ma non so fino a che punto
>>giustificata.
>Qui la discussione sarebbe molto lunga, e gia' ora siamo parecchio OT.
Mi ero dimenticato di dirti che il progetto lo volevo sviluppare in
java :-)
Ora 'e vero che bisognerebbe sempre leggersi il manifesto dei gruppi
ai quali si partecipa, ma non credo che questi argomenti siano molto
distanti da quelli indicati sul manifesto ...
Ad ogni modo se invece mi sbaglio, e questi argomenti non rientrano
in nessun modo nel tema che sta a cuore a chi ha sottoscritto questo
gruppo, invito chiunque a correggermi.
>Comunque anche qui
>e' una questione di approccio. Tanto per buttare un sasso ti posso dire che OO *non* e' un
>metodo per modellare la realta'. Ti risulta?
Mi sfugge il senso della domanda? Potresti essere un po' piu' chiaro?
>>Quindi esiste comunque una relazione tra la struttura delle classi e
>>la simulazione dei diagrammi dinamici.
>Ma secondo te quali potrebbero essere i diagrammi piu' importanti nel mondo OO? E perche'?
Quelli nel nostro cervello? Perche' non diventano mai obsoleti, e sono
facili da comunicare? :-))
L'ho buttata li', prendila come una battuta, non vuole essere un
distillato di filosofia :-)
>>Ma, se non ho capito male c'e' di piu' e di meglio:
>(e per fortuna :-D)
Gia':-)
>>Non so a te, ma a me tutto cio' appare abbastanza interessante. Certo
>>che vorrei provare a mettere le mani su qualcosa e fare dei test :-))
>>prima di dare un giudizio definitivo sulla praticabilita' ed
>>efficiacia di un tale approccio ... :-)
>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?
A dire il vero cio' che cerco e' proprio la semplicita', ovvero la
capacita' di astrarre dai dettagli del codice per poter ragionare piu'
liberamente.
Se l'UML, integrato nell'ambiente di programmazione (i diagrammi, a
questo punto diventerebbero a tutti gli effetti parte del codice!),
puo' essere utile in questo senso, perche' non dargli almeno una
chance? Un altro risultato importante che si potrebbe raggiungere in
questo modo sarebbe quello di mantenere una documentazione espressa
con un linguaggio grafico, maggiormente comprensibile dal cliente
finale.
Ti dico la sincera verita' che fin'ora non ho ancora utilizzato l'UML
in un progetto, per cui puo' darsi che stia prendendo lucciole per
lanterne, ma non riesco a immaginare perche' l'adozione dell'UML
dovrebbe complicare piuttosto che semplificare lo sviluppo del
progetto.
Sono aperto ad approfondire ogni controindicazione che vorrai
indicarmi ovviamente :-)
>Dai, leggi l'articolo :-) e guarda che cantonata prenderebbero i due amici partendo dal
>design (diagramma UML).
Ti prometto che ti rispondo su questo punto non appena lo avro' letto
:-)
ciao, Michele
Michele Bendazzoli
wrote:
>Dai, ti vedo gia' abbandonare la strada oscura dell'anticipazione e prendere la limpida
>via del test firs incrementale :-)
Se la curiosita' e' il primo sintomo di un giustificato interesse (e'
forse la curiosita', la molla che spinge a fare i test?:-), direi che
ci sono buone probabilita' che finisca proprio in questo modo :-)
>Hey, complimenti!
Grazie, anche se avrei preferito che a farmeli fosse qualcuno a cui
interessasse veramente l'argomento ... il colmo dell'ironia e' che
dell'argomento non avevo la piu' pallida idea finche' non mi e' stato
proposto, e di cio' ero ovviamente perfettamente conscio: quello che
non mi era chiaro e' che dell'argomento non aveva la piu' pallida idea
neanche chi me lo stava proponendo ... :-)
>>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* :-))
>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
Bruno Bossola
>On Mon, 13 Aug 2001 08:15:56 GMT, bbos...@hotmail.com (Bruno Bossola)
>wrote:
>
>
>>Non segue proprio XP. Delle 12 pratiche che dovrebbe implementare, il suo metodo ne
>>realizza molte meno. Per fare XP devi implementare tutte le pratiche (e' questo che
>>intendi per "puro"?) se implementi solo quelle che ti fanno comodo a te o che ti piacciono
>>di piu', e altre semplicemente non le consideri allora non stai facendo XP.
>>
>>Comunque se intendi quello con XP pura sono d'accordo: XP si fa solo se il tuo metodo
>>implementa tutte e 12 le pratiche.
>
>In sostanza si', anche se credo che alcune delle regole siano da
>prendere con il beneficio dell'inventario...
>
Nessuna, non devi solo avere paura. Ed essere skillato.
>...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'?!
>
Si! Avere il cliente a fianco e' il massimo! Noi ci dobbiamo accontentare di averlo su un
altro piano, ma sopportiamo le scale stoicamente :-) E a fianco devi avere il cliente,
ovvero l'utente finale, non un suo proxy :-D
>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...
>
Uh? Non ho capito.
Michele Bendazzoli
Bendazzoli) wrote:
>>Dai, leggi l'articolo :-) e guarda che cantonata prenderebbero i due amici partendo dal
>>design (diagramma UML).
>
>Ti prometto che ti rispondo su questo punto non appena lo avro' letto
>:-)
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
Michele Bendazzoli
wrote:
>Si! Avere il cliente a fianco e' il massimo! Noi ci dobbiamo accontentare di averlo su un
>altro piano, ma sopportiamo le scale stoicamente :-) E a fianco devi avere il cliente,
>ovvero l'utente finale, non un suo proxy :-D
Ho capito che e' il massimo, ma se il cliente invece che stare al
piano di sopra sta in una citta' che dista una cinquantina di km ...
che fai ... mica lo puoi andare a prendere ogni mattina con
l'elicottero ... :-)
Bisogna vedere la portata del progetto, quanto e' importante per
l'azienda per cui lavora, il referente di cui hai bisogno, quanto vale
il vale per il cliente il progetto che stai facendo, quanto infine la
sua percezione da parte di chi decide ... Mi sembra difficile poter
giustificare un tale passo.
>>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...
>Uh? Non ho capito.
E' oziosa nel senso che (nell'esempio che ti sto portando) non e' una
opzione praticabile purtroppo ...
ciao, Michele
Cristiano Sadun
>"Il motivo e' che UML e' stato disegnato da anticipazionisti, persone
>convinte che realizzare un sistema software sia analogo a realizzare
>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.
Michele Bendazzoli
wrote:
>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.
*Rischiamo* solo pero', alla fine vedrai che butteremo via solo
l'acqua *sporca* (non ho capito cosa hai contro l'acqua calda :-)
ciao, Michele
Cristiano Sadun
@news.galactica.it>:
>(non ho capito cosa hai contro l'acqua calda :-)
E' che in Norvegia se ne fa un gran uso ;-)
Bruno Bossola
>>metodo per modellare la realta'. Ti risulta?
>
>Mi sfugge il senso della domanda? Potresti essere un po' piu' chiaro?
>
La mia domanda era una provocazione. Tu fa che parte stai?
>>>Quindi esiste comunque una relazione tra la struttura delle classi e
>>>la simulazione dei diagrammi dinamici.
>
>>Ma secondo te quali potrebbero essere i diagrammi piu' importanti nel mondo OO? E perche'?
>
Sicuramente i + importanti sono collaboration e sequence, perche' mostrano la dinamica di
collaborazione degli oggetti.
>>>Non so a te, ma a me tutto cio' appare abbastanza interessante...
>>
>>Ma il problema e': tutto questo serve veramente a qualcosa?...
>
>A dire il vero cio' che cerco e' proprio la semplicita', ovvero la
>capacita' di astrarre dai dettagli del codice per poter ragionare piu'
>liberamente.
>Se l'UML, integrato nell'ambiente di programmazione (i diagrammi, a
>questo punto diventerebbero a tutti gli effetti parte del codice!),
>puo' essere utile in questo senso, perche' non dargli almeno una
>chance? Un altro risultato importante che si potrebbe raggiungere in
>questo modo sarebbe quello di mantenere una documentazione espressa
>con un linguaggio grafico, maggiormente comprensibile dal cliente
>finale.
>Ti dico la sincera verita' che fin'ora non ho ancora utilizzato l'UML
>in un progetto, per cui puo' darsi che stia prendendo lucciole per
>lanterne, ma non riesco a immaginare perche' l'adozione dell'UML
>dovrebbe complicare piuttosto che semplificare lo sviluppo del
>progetto.
>Sono aperto ad approfondire ogni controindicazione che vorrai
>indicarmi ovviamente :-)
>
Prova, poi ne parleremo forse ancora :-D
Bruno Bossola
>On Mon, 13 Aug 2001 12:58:29 GMT, micky...@galactica.it (Michele
>Bendazzoli) wrote:
>
>
>>>Dai, leggi l'articolo :-) e guarda che cantonata prenderebbero i due amici partendo dal
>>>design (diagramma UML).
>>
>>Ti prometto che ti rispondo su questo punto non appena lo avro' letto
>>:-)
>
>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
>.. :-)
>
Falli, falli :-D
>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?
I pattern di design emergono durante la fase di refactoring. Tu devi essere in grado di
riconoscerli, di individuarli, e per fare questo devi conoscerli perfettamente. Dopo un
po' di refactoring, un po' di riassegnazione di responsabilita', di solito i pattern sono
li che ti aspettano: devi solo aiutarli ad uscire :-D e di solito essi aiutano, se usati
in questo modo, ad abbassare la complessita.
>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?
>
Uhm... non capisco, in XP si parla di metafora, non di architettura. Puoi spiegarti
meglio?
Bruno Bossola
>On Mon, 13 Aug 2001 15:12:58 GMT, bbos...@hotmail.com (Bruno Bossola)
>wrote:
>
>
>>Si! Avere il cliente a fianco e' il massimo! Noi ci dobbiamo accontentare di averlo su un
>>altro piano, ma sopportiamo le scale stoicamente :-) E a fianco devi avere il cliente,
>>ovvero l'utente finale, non un suo proxy :-D
>
>Ho capito che e' il massimo, ma se il cliente invece che stare al
>piano di sopra sta in una citta' che dista una cinquantina di km ...
>che fai ... mica lo puoi andare a prendere ogni mattina con
>l'elicottero ... :-)
>Bisogna vedere la portata del progetto, quanto e' importante per
>l'azienda per cui lavora, il referente di cui hai bisogno, quanto vale
>il vale per il cliente il progetto che stai facendo, quanto infine la
>sua percezione da parte di chi decide ... Mi sembra difficile poter
>giustificare un tale passo.
>
In effetti, c'e' un problema di educazione del cliente, che deve rendersi conto *quanto*
vale realizzare il progetto. Se secondo lui e' piu' conveniente fare lavorare a tempo
pieno la sua persona invece di metterla nel team, beh, allora magari il progetto parte
male gia' in partenza. Leggi il capitolo su XP explained.
>>>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...
>
>>Uh? Non ho capito.
>
>E' oziosa nel senso che (nell'esempio che ti sto portando) non e' una
>opzione praticabile purtroppo ...
>
Peccato. Fate in modo comunque di avere una soluzione alternativa (videoconferenza, linea
dedicata, telefono)
Bruno Bossola
>micky...@galactica.it (Michele Bendazzoli) wrote in
><3b73e2fc...@news.galactica.it>:
>
>>"Il motivo e' che UML e' stato disegnato da anticipazionisti, persone
>>convinte che realizzare un sistema software sia analogo a realizzare
>>un ponte su un fiume."
>
>Ecco, questo e' eccessivo. :-)
>
Beh, direi provocatorio per la seconda parte. Ma guarda che fino a cinque o sei anni fa
l'intera SE era cosi: costruire un software e' come realizzare un automobile. Il ciclo
classico era analisi -> progetto -> produzione che guarda caso mappa proprio il waterfall
(caro vecchio Royce!) analisi -> design -> codifica. Adesso ci stiamo accorgendo che non
e' proprio cosi. Ma secondo me sono ancora in molti quelli che fanno finta di non vedere.
E ad esempio intorno a me persone che ci credono ancora fermamente ne trovo, parecchi.
Senza parlare di alcuni dotti project manager, guarda anche solo i commerciali che vendono
progetti fixed scope / fixed date / fixed resources e che ci credono :-)
>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. ;-)
>
Anche Gamma, Helm, Johnson e Vlissides hanno fatto lo stesso. Ma un conto e' usare i DP in
modo anticipazionista, un altro e' usarli ex-post.
>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.
>
Nessuno vuole buttare via niente, stiamo solo discutende delle opportunita' di uso che
hanno certi strumenti.
Michele Bendazzoli
wrote:
>In effetti, c'e' un problema di educazione del cliente, che deve rendersi conto *quanto*
>vale realizzare il progetto. Se secondo lui e' piu' conveniente fare lavorare a tempo
>pieno la sua persona invece di metterla nel team, beh, allora magari il progetto parte
>male gia' in partenza. Leggi il capitolo su XP explained.
L'ho letto, e' per questo che mi sti chiedendo quanto puo' incidere.
Ad ogni modo esistono anche altri mezzi di comunicazione, per quanto
sempre meno efficaci rispetto al contatto diretto ... cercheremo di
arrangiarci ;-)
>Peccato. Fate in modo comunque di avere una soluzione alternativa (videoconferenza, linea
>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
Michele Bendazzoli
wrote:
>I pattern di design emergono durante la fase di refactoring. Tu devi essere in grado di
>riconoscerli, di individuarli, e per fare questo devi conoscerli perfettamente. Dopo un
>po' di refactoring, un po' di riassegnazione di responsabilita', di solito i pattern sono
>li che ti aspettano: devi solo aiutarli ad uscire :-D e di solito essi aiutano, se usati
>in questo modo, ad abbassare la complessita.
In effetti avevo percepito che questa poteva essere l'approccio
leggendo l'articolo che mi hai postato: e' nell'ultima fase, quella di
rifatorizzazione in cui si prendono cura di creare la classe score,
per andare incontro al sano principio di assegnare le responsabilita'
a chi ha la conoscenze necessarie ... o sbaglio? :-)
>>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?
>Uhm... non capisco, in XP si parla di metafora, non di architettura. Puoi spiegarti
>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
Michele Bendazzoli
wrote:
>>Mi sfugge il senso della domanda? Potresti essere un po' piu' chiaro?
>Nel software engineering "tradizionale" OO e' visto come un modo di modellare la realta'.
>La mia domanda era una provocazione. Tu fa che parte stai?
Molto scettico rispetto alla possibilita' anche solo di avvicinarci
alla realta': quale realta' poi, quella del nostro cervello, o quella,
che nasconde gli infiniti segreti che Dio ha deciso di non rivelarci
(ancora perlomeno:-)?
>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
Michele Bendazzoli
(Michele Bendazzoli) wrote:
>Ok, anche se per quello che avevo in mente (Poseidon) mi pare che
>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
Bruno Bossola
wrote:
>On Thu, 16 Aug 2001 12:53:34 GMT, bbos...@hotmail.com (Bruno Bossola)
>wrote:
>
>
>>I pattern di design emergono durante la fase di refactoring. Tu devi essere in grado di
>>riconoscerli, di individuarli, e per fare questo devi conoscerli perfettamente. Dopo un
>>po' di refactoring, un po' di riassegnazione di responsabilita', di solito i pattern sono
>>li che ti aspettano: devi solo aiutarli ad uscire :-D e di solito essi aiutano, se usati
>>in questo modo, ad abbassare la complessita.
>
>In effetti avevo percepito che questa poteva essere l'approccio
>leggendo l'articolo che mi hai postato: e' nell'ultima fase, quella di
>rifatorizzazione in cui si prendono cura di creare la classe score,
>per andare incontro al sano principio di assegnare le responsabilita'
>a chi ha la conoscenze necessarie ... o sbaglio? :-)
>
Non sbagli, ma in quella fase i due hanno appena iniziato. In realta' l'attivita' di
refactoring e' in assoluto quella + pesante di tutto il microciclo, e devi essere
veramente bravo per fermarti. Comunque, e' da provare. Non potete al limite fare dei
corsi?
>>>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?
>
>>Uhm... non capisco, in XP si parla di metafora, non di architettura. Puoi spiegarti
>>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.
>
L'architettura in XP, ti "viene incontro", e la scopri a mano a mano che il cliente ti
richiede funzionalita' e a mano a mano che tu ne risolvi le complessita'. Comunque
considerala sempre come un mezzo, non un fine, e poi cerca sempre di rimanere non
accoppiato con essa, senza anticipare alcun cambiamento ma semplicemente lavorando object
oriented :-) (per farti un esempio non permettere che un cambiamento su un database ti
costringa a riscrivere un pezzo di GUI)
>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 ... :-(
>
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
Bruno Bossola
>>>Mi sfugge il senso della domanda? Potresti essere un po' piu' chiaro?
>
>>Nel software engineering "tradizionale" OO e' visto come un modo di modellare la realta'.
>>La mia domanda era una provocazione. Tu fa che parte stai?
>
>Molto scettico rispetto alla possibilita' anche solo di avvicinarci
>alla realta': quale realta' poi, quella del nostro cervello, o quella,
>che nasconde gli infiniti segreti che Dio ha deciso di non rivelarci
>(ancora perlomeno:-)?
>
Ottimo. Infatti OO non e' un mezzo per modellare la realta', e' un buon meccanismo di
collaborazione. Che ne dici?
>>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? ... :-))
>
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
Michele Bendazzoli
wrote:
>Non sbagli, ma in quella fase i due hanno appena iniziato. In realta' l'attivita' di
>refactoring e' in assoluto quella + pesante di tutto il microciclo, e devi essere
>veramente bravo per fermarti. Comunque, e' da provare. Non potete al limite fare dei
>corsi?
Ma, fra gli acquisti dell'estate, ho preso vari libri, "applying uml
and patterns" di Craig Larman, "Refactoring" di Fowler, "Analisys
Pattern" ancora di Fowler, e infine "Enterprise Java Patterns" (?,
questo deve ancora arrivarmi ...), spero tutto cio' mi possa aiutare:
ad ogni modo fare qualche corso sicuramente non farebbe male, anzi
credo sia possibile sfruttare i finanziamenti europei in questo senso,
a patto, mi pare, di trovare almeno otto persone interessate al corso
(ma forse questo non e' un grosso problema), e soprattutto una persona
competente in grado di tenerlo, non vorrei perdere tempo inutilmente,
dato che ne ho veramente poco ...: tu conosci qualcuno di valido?
>L'architettura in XP, ti "viene incontro", e la scopri a mano a mano che il cliente ti
>richiede funzionalita' e a mano a mano che tu ne risolvi le complessita'. Comunque
>considerala sempre come un mezzo, non un fine, e poi cerca sempre di rimanere non
>accoppiato con essa, senza anticipare alcun cambiamento ma semplicemente lavorando object
>oriented :-) (per farti un esempio non permettere che un cambiamento su un database ti
>costringa a riscrivere un pezzo di GUI)
Uhm..., qui mi pare che stai barando un po' :-)
Come fai a scoprire che hai bisogno di java enterprise, mano a mano
che sviluppi le funzionalita'? Quelle funzionalita' dovrai pur
svilupparle con qualche tecnologia, e sarebbe disdicevole dover
cambiare tecnologia dopo un po' che hai iniziato a sviluppare
funzionalita', per quanto, come tu stesso suggerisci, seguendo un
approccio corretto si dovrebbero limitare il piu' possibile le
dipendenze dalla tecnologia: certo che anche quest'ultimo approccio
*costa* in termini di complessita', a fronte di un possibile vantaggio
*futuro* vantaggio quindi solo *teorico* ... un po' in contraddizione
con la filosofia XP: o sbaglio? :-))
>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
Ti ringrazio per l'informazione, vedro' di iscrivermi non appena mi
metto a posto con l'indirizzo e-mail.
ciao, Michele
Michele Bendazzoli
wrote:
>Ottimo. Infatti OO non e' un mezzo per modellare la realta', e' un buon meccanismo di
>collaborazione. Che ne dici?
Se dovro' diventare un Xper, bisogna che inizi con il piede giusto,
ovvero dicendo pane al pane e vino al vino: se vuoi che ti dica con
sincerita' la mia opinione credo che la tua affermazione sia corretta
ma un po' limitativa :-)
E' vero infatti che supportare bene la collaborazione implica
supportare bene anche la *comunicazione*, e quindi sottolineare la
capacita' dell'OO di esprimere con una certa facilita' alcuni concetti
tipici del nostro modo di pensare (*non* della realta'! :-), ovvero la
generalizzazione, l'ereditarieta', l'incapsulazione, il poliformismo
ecc.), ma credo che questa capacita' espressiva abbia un valore in
se', che va al di la' del mero supporto alla collaborazione: per fare
un esempio banale, credo che se una singola persona dovesse sviluppare
un intero progetto, avrebbe convenienza comunque ad utilizzare un
approccio OO, sebbene in questo caso non sia di nessun aiuto alla
collaborazione per il semplice fatto, che in questo caso, la
collaborazione non esiste nemmeno! Che ne dici?
>>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? ... :-))
>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
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
Cristiano Sadun
<3b7bbf6a.1317236015@MI008IT-EFD01>:
>Ma guarda che fino a
>cinque o sei anni fa l'intera SE era cosi: costruire un software e' come
>realizzare un automobile.
Mi fa piacere che 'ste cose stiano entrando nel patrimonio comune, visto
che le vo' ripetendo da appunto circa cinque anni. ;-)
>Il ciclo classico era analisi -> progetto ->
>produzione che guarda caso mappa proprio il waterfall (caro vecchio
>Royce!) analisi -> design -> codifica.
[La diatriba e' accademica (e irrilevante) ma dato che tra noi non ci
sono rischi di flames, proseguo. :)]
E' proprio il mio punto. Quello era (ed e' spesso tuttora) il ciclo
classico anni '80 in IT commerciale. Il lavoro di molti metodologisti nei
tardi '80 e nei primi '90 (e, nota, dello stesso Boehm, successivo a
waterfall, con lo spiral ed evoluzioni) e' proprio per superare wf - e
molto di quel lavoro confluisce in UML&RUP o simili (per non parlare dei
processi lightweight). Prendi gli use case, ad esempio, da usare come
base per lo sviluppo, in un ordine dettato solo (e debolmente) dalle
mutue interrelazioni, ma con un'attenzione notevole a mappare BLUC giu'
fino a DLUC (e' interessante che chi di UML conosce la notazione ma non
ha assimilato i processi si domandi spesso a che diavolo servono gli UC
:). O il RAD di IBM (e Rambaugh li' lavorava). Il modello
iterativo/incrementale (di cui XP e', appunto, un'estremizzazione) nasce
da quelli sforzi. Sono quelle le persone dietro ad UML - e la loro
comprensione delle dinamiche del processo di sviluppo software non e'
esattamente minima (alla "ponte", per intenderci.. quella e' la
comprensione del project manager o del CTO tipico che arriva da
tutt'altro ambito.. ma non di chi ha *ideato* UML&c). XP (e Beck e' il
primo a dirlo) non nasce dal nulla.
Chiaro che nel frattempo il mondo IT commerciale, per ovvi motivi, e'
rimasto indietro, e spesso ha preso solo etichette e notazioni ma senza
realmente comprendere il metodo - un po' come succedeva anni fa quando si
provava a far passare programmatori COBOL a C++.. spesso dicevano "si',
ho capito", facevano classi, che classi erano solo di nome. :)
Per dire, e' come se tra dieci anni qualcuno dicesse che XP e'
...blahblahblah.. e Kent non capisce niente di software perche' in IT
commerciali progetti commerciali hanno fatto qualcosa e gli hanno
appiccicato l'etichetta XP.
In estrema sintesi, i creatori di UML non sono esattamente imbecilli (se
non altro, lo dimostra il fatto che vivono - e bene - di pura consulenza
:).
>Adesso ci stiamo accorgendo che non e' proprio cosi.
Il problema e' il "ci". :-) Io ho usato molto spesso in passato, pure sui
ng, frasi identiche (e la metafora del "ponte" e' una fav of mine) ma il
punto e' che c'e' in giro gente che ancora non si e' accorta, e c'e' in
giro gente che se ne e' accorta quindici anni fa. Booch&c sono tra i
secondi, non i primi - ma cio' non evita che ci sia un sacco di gente in
giro che, cosi' come non ha letto o apprezzato Booch in passato, non
leggera' e non apprezzera' Beck oggi. :-)
>Ma secondo me sono ancora in molti quelli che fanno
>finta di non vedere. E ad esempio intorno a me persone che ci credono
>ancora fermamente ne trovo, parecchi.
Bingo. Ma non e' certo colpa di Booch, Rumbaugh, Martin&c. Il mio rimedio
classico per la situazione e' di mettere in posizione di medio management
gente che abbia competenza tecnica in programmazione *e* interesse e
competenza in ingengneria del software (non basta saper programmare; e
non basta saper la teoria dei cicli di sviluppo). Questo tendeva a
suscitare parecchi ohhh e ahhh quando "ingengeria del software" era un
termine ignoto ai piu' *in* ambito informatico.
Oggidi', vedo da me il problema: di gente cosi' ce n'e' semplicemente
troppo poca.
>Senza parlare di alcuni dotti
>project manager, guarda anche solo i commerciali che vendono progetti
>fixed scope / fixed date / fixed resources e che ci credono :-)
<boasting mode>
Oh, ma i miei progetti sono in genere cosi'. On schedule, on budget,
minimum resources (ridendo):-) Il trucco e' che *io* fisso budget,
schedule e risorse, non i commerciali (nel qual caso, rifiuto
responsabilita' ;-).
</boasting mode>
>Anche Gamma, Helm, Johnson e Vlissides hanno fatto lo stesso. Ma un
>conto e' usare i DP in modo anticipazionista, un altro e' usarli
>ex-post.
Concordo per la GOF. Io per esempio uso DP in modo anticipazionista a
volte, e a volte no, e mi trovo piuttosto bene. Tutto sta a vedere cosa
intendi per "semplice". :-)
>Nessuno vuole buttare via niente, stiamo solo discutende delle
>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'.
habana
lunedi' parto per le vacanze (finalmente) ma non ho resistito a scrivere
perche'...
>>No. Uno dei principi di XP e' umilta'. E io ci ho messo un bel po' a
>>capirlo: dopo 12 anni che sviluppavo software, credevo di avere
>>capito tutto di OOA, OOD, ecc ecc.
>>Invece non avevo capito molto. E' dura da ammettere, ma come dice
>>Francesco, il mio mentor, "prima di riempire la tazza bisogna
>>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
Bruno Bossola
>bbos...@hotmail.com (Bruno Bossola) wrote in
><3b7bbf6a.1317236015@MI008IT-EFD01>:
>
>>Ma guarda che fino a cinque o sei anni fa l'intera SE era cosi:
>>costruire un software e' come realizzare un automobile.
>
>Mi fa piacere che 'ste cose stiano entrando nel patrimonio comune, visto
>che le vo' ripetendo da appunto circa cinque anni. ;-)
>
Forse le hai ripetute alle persone sbagliate :-D
>>Il ciclo classico era analisi -> progetto ->
>>produzione che guarda caso mappa proprio il waterfall (caro vecchio
>>Royce!) analisi -> design -> codifica.
>
>[La diatriba e' accademica (e irrilevante) ma dato che tra noi non ci
>sono rischi di flames, proseguo. :)]
>
>E' proprio il mio punto. Quello era (ed e' spesso tuttora) il ciclo
>classico anni '80 in IT commerciale. Il lavoro di molti metodologisti nei
>tardi '80 e nei primi '90 (e, nota, dello stesso Boehm, successivo a
>waterfall, con lo spiral ed evoluzioni) e' proprio per superare wf - e
>molto di quel lavoro confluisce in UML&RUP o simili (per non parlare dei
>processi lightweight).
>
Uhm... sicuramente Bohem a contribuito allo sviluppo dei processi lightweight, ma tieni
conto che lui era (e'?) un accanito sostenitori dei generatori di applicazioni, i mitici
4GL, dove la complessita' viene risolta con complessita. Esattamente l'inverso di quello
cui tende XP, che usa invece la semplicita'.
>Prendi gli use case, ad esempio, da usare come
>base per lo sviluppo, in un ordine dettato solo (e debolmente) dalle
>mutue interrelazioni, ma con un'attenzione notevole a mappare BLUC giu'
>fino a DLUC (e' interessante che chi di UML conosce la notazione ma non
>ha assimilato i processi si domandi spesso a che diavolo servono gli UC
>:).
BLUC? DLUC? SBLUB? :-)
Meglio se chiariamo le sigle, non ti sembra? Se mi metto a parlare a sigle con XP ti vedo
molto male :-) Comunque io per gli use case (UC) adotto l'approccio di Larman: high_level
/ expanded ed essential / real. Ovviamente il lavoro di Jacobson e' insostituibile
(inchino rituale!) ma mi trovo meglio con la suddivisione "a la Larman" :-D
In XP comunque, di fatto, si parte proprio dagli use case, anche se non si ha quella
tracciabilita' all'interno dei vari modelli che Jacobson vorrebbe: questo principalmente
perche' c'e' solo il codice :-D
>O il RAD di IBM (e Rambaugh li' lavorava).
Gia'. A che serve? (eh eh eh) (Ah, sto parlando del RAD, ovviamente :-D)
>Il modello iterativo/incrementale (di cui XP e', appunto, un'estremizzazione)
>nasce da quelli sforzi. Sono quelle le persone dietro ad UML - e la loro
>comprensione delle dinamiche del processo di sviluppo software non e'
>esattamente minima (alla "ponte", per intenderci.. quella e' la
>comprensione del project manager o del CTO tipico che arriva da
>tutt'altro ambito.. ma non di chi ha *ideato* UML&c). XP (e Beck e' il
>primo a dirlo) non nasce dal nulla.
>
Mi spiace, io non vedo UML come condizione per arrivare a XP. Per arrivare a XP ci vuole
esperienza, un sacco di esperienza: sicuramente coloro che hanno contribuito a sviluppare
UML hanno contribuito, anche se non direttamente, allo sviluppo di XP. Sicuramente un
sacco di persone che non hanno contribuito a UML hanno contribuito a XP. Semplicemente con
l'esperienza.
>Chiaro che nel frattempo il mondo IT commerciale, per ovvi motivi, e'
>rimasto indietro, e spesso ha preso solo etichette e notazioni ma senza
>realmente comprendere il metodo - un po' come succedeva anni fa quando si
>provava a far passare programmatori COBOL a C++.. spesso dicevano "si',
>ho capito", facevano classi, che classi erano solo di nome. :)
>
>Per dire, e' come se tra dieci anni qualcuno dicesse che XP e'
>...blahblahblah.. e Kent non capisce niente di software perche' in IT
>commerciali progetti commerciali hanno fatto qualcosa e gli hanno
>appiccicato l'etichetta XP.
>
No, guarda che non ci capiamo, non sto assolutamente criticando UML o le persone che ci
stanno dietro, stop!, non voglio dare ad intendere questo. Semplicemente dico che hanno
proposto (alcuni propongono ancora) un approccio allo sviluppo del software che produce
risultati inferiori a quelli che puoi produrre usando XP.
>In estrema sintesi, i creatori di UML non sono esattamente imbecilli (se
>non altro, lo dimostra il fatto che vivono - e bene - di pura consulenza
>:).
>
Nessuno sta dicendo questo, assolutamente, per nulla! Anche Royce, che se pur male
interpretato ha causato la nascita del waterfall, ha tutto il mio rispetto e cosi tutti
gli altri. Assolutamente. Non e' questo il punto. Il punto e' che l'anticipazione porta
con se' complessita', e questa non e' una strada da seguire.
>>Adesso ci stiamo accorgendo che non e' proprio cosi.
>
>Il problema e' il "ci". :-) Io ho usato molto spesso in passato, pure sui
>ng, frasi identiche (e la metafora del "ponte" e' una fav of mine) ma il
>punto e' che c'e' in giro gente che ancora non si e' accorta, e c'e' in
>giro gente che se ne e' accorta quindici anni fa. Booch&c sono tra i
>secondi, non i primi - ma cio' non evita che ci sia un sacco di gente in
>giro che, cosi' come non ha letto o apprezzato Booch in passato, non
>leggera' e non apprezzera' Beck oggi. :-)
>
Questo e' vero. Quando posso, io cerco di spiegare quali sono i vantaggi di XP e di un
approccio iterativo incrementale stretto ìn vece di approcci + classici.
>>Ma secondo me sono ancora in molti quelli che fanno
>>finta di non vedere. E ad esempio intorno a me persone che ci credono
>>ancora fermamente ne trovo, parecchi.
>
>Bingo. Ma non e' certo colpa di Booch, Rumbaugh, Martin&c. Il mio rimedio
>classico per la situazione e' di mettere in posizione di medio management
>gente che abbia competenza tecnica in programmazione *e* interesse e
>competenza in ingengneria del software (non basta saper programmare; e
>non basta saper la teoria dei cicli di sviluppo). Questo tendeva a
>suscitare parecchi ohhh e ahhh quando "ingengeria del software" era un
>termine ignoto ai piu' *in* ambito informatico.
>
>Oggidi', vedo da me il problema: di gente cosi' ce n'e' semplicemente
>troppo poca.
>
Basta farrgli svuotare la tazza :-) e riempirla nuovamente. Certo e' che se "fin da
piccoli" gli dicono che OO e' un buon metodo per modellare la realta'... vedi tu.
Io sto ora mettendo un po' a posto la casa e sto dando il bianco: ho provato
*personalmente* a mettermi davanti al muro dicendogli "muro, dipingiti!" ma non funziona!
Neanche con i libri, "libro apriti a pagina X!". Eppure nel software funziona cosi.. mah!
Vorra' dire qualcosa? :-D
>>Senza parlare di alcuni dotti
>>project manager, guarda anche solo i commerciali che vendono progetti
>>fixed scope / fixed date / fixed resources e che ci credono :-)
>
><boasting mode>
>Oh, ma i miei progetti sono in genere cosi'. On schedule, on budget,
>minimum resources (ridendo):-) Il trucco e' che *io* fisso budget,
>schedule e risorse, non i commerciali (nel qual caso, rifiuto
>responsabilita' ;-).
></boasting mode>
>
Questo lo facevo anche io, ma purtroppo non e' sempre sufficiente a reggere il
cambiamento. I requisiti cambiano, il cliente cambia idea, e se non hai flessibilita' nel
contratto che stipuli non riesci a gestirlo. Anche se sei un mago del software.
Attualmente secondo me il modo migliore di sviluppare software e' affittare il team presso
il cliente, con il cliente che ti lavora a fianco, cosi' e' il massimo. Se potessi tornare
indietro di un tre anni, almeno un progetto sarebbe andato oggi sulla via giusta.
>>Anche Gamma, Helm, Johnson e Vlissides hanno fatto lo stesso. Ma un
>>conto e' usare i DP in modo anticipazionista, un altro e' usarli
>>ex-post.
>
>Concordo per la GOF. Io per esempio uso DP in modo anticipazionista a
>volte, e a volte no, e mi trovo piuttosto bene. Tutto sta a vedere cosa
>intendi per "semplice". :-)
>
Non complicato :-D
Potrei dire cbe una soluzione e' semplice se non anticipa nulla o se chiunque nel tuo team
semplicemente leggendo il codice ne comprende perfettamente il funzionamento.
Comunque Beck dice che il codice e' semplice quando:
- fa funzionare tutti i test
- esprime tutte le idee che tu hai bisogno di esprimere
- non contiene duplicazioni
- ha il numero minimo di classi e metodi
>>Nessuno vuole buttare via niente, stiamo solo discutende delle
>>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'.
>
L'industria siamo noi :-)
Bruno Bossola
>>>No. Uno dei principi di XP e' umilta'. E io ci ho messo un bel po' a
>>>capirlo: dopo 12 anni che sviluppavo software, credevo di avere
>>>capito tutto di OOA, OOD, ecc ecc.
>>>Invece non avevo capito molto. E' dura da ammettere, ma come dice
>>>Francesco, il mio mentor, "prima di riempire la tazza bisogna
>>>svuotarla.". Io ti consiglio di svuotare la tazza.
>
>... ditemi come svuotare la tazza.
>
Eh, devi dimenticare tutto quello che credi di sapere e ricominciare da capo, studiando i
testi giusti :-) Poi, una volta che l'hai fatto, ridimentichi di nuovo tutto ed inizi ad
usare XP. Non e' facile.
Per quanto riguarda i libri, ne trovi un nutrito elenco sul sito del mio mentor,
www.xplabs.com. Alternativamente, ti consiglio un bel corso :-)
>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?
>
Beh, uhm... di articoli su XP ce ne sono *parecchi*, vediamo se trovo qualcosa di
introduttivo decente.... l'ideale sarebbe comunque il libro di Beck, XP eXplained, ma ci
sono anche un bel po' di risorse in rete, ovviamente tutte in inglese (per ora :-D)
Allora, in primis un articolo leggibile anche dai non addetti ai lavori:
http://www.cio.com/archive/070101/secret.html
Poi un paio di articoli introduttivi di IBM per tecnici:
http://www-106.ibm.com/developerworks/library/i-extreme/?n-dd-751
http://www-106.ibm.com/developerworks/ibm/library/j-xp/index.html
Quindi il link ai siti istutuzionali:
http://www.extremeprogramming.org/
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
http://www.xprogramming.com/
Fammi sapere se ti basta :-)
>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... :)
>
Per quanto riguarda me, vedi sopra :-D
>e non sognatevi di fare queste discussioni in privato, qui ascoltiamo e
>impariamo!!
>
Tranquillo, il NG e' qui apposta per noi!
Cristiano Sadun
>Forse le hai ripetute alle persone sbagliate :-D
A chiunque capitasse. ;-)
>Uhm... sicuramente Bohem a contribuito allo sviluppo dei processi
>lightweight, ma tieni conto che lui era (e'?) un accanito sostenitori
>dei generatori di applicazioni, i mitici 4GL, dove la complessita' viene
>risolta con complessita. Esattamente l'inverso di quello cui tende XP,
>che usa invece la semplicita'.
Intendevo solo dire che waterfall e' state of the art anni '70; e lo
state of the art *e'* cambiato molto prima di oggi.
E' la penetrazione nell'industria che e' una cosa diversa.
>BLUC? DLUC? SBLUB? :-)
Scusa, business-level UC e development-level UC. :-)
>>O il RAD di IBM (e Rambaugh li' lavorava).
>Gia'. A che serve? (eh eh eh) (Ah, sto parlando del RAD, ovviamente :-D)
Ad illustrare che waterfall era, gia' 15 anni fa, ben lungi dall'essere
pensato come il meglio possibile. :-)
>Mi spiace, io non vedo UML come condizione per arrivare a XP.
Non parlavo di UML, ma di modello iterativo/incrementale.
E di progresso storico, non di condizioni. :-)
>Per
>arrivare a XP ci vuole esperienza, un sacco di esperienza: sicuramente
>coloro che hanno contribuito a sviluppare UML hanno contribuito, anche
>se non direttamente, allo sviluppo di XP. Sicuramente un sacco di
>persone che non hanno contribuito a UML hanno contribuito a XP.
>Semplicemente con l'esperienza.
...
>No, guarda che non ci capiamo, non sto assolutamente criticando UML o le
>persone che ci stanno dietro, stop!,
Io rispondevo a chi (forse Michele) affermava che
<quote>
"Il motivo e' che UML e' stato disegnato da anticipazionisti, persone
convinte che realizzare un sistema software sia analogo a realizzare
un ponte su un fiume."
</quote>
Altro non so. :-)
>non voglio dare ad intendere
>questo. Semplicemente dico che hanno proposto (alcuni propongono ancora)
>un approccio allo sviluppo del software che produce risultati inferiori
>a quelli che puoi produrre usando XP.
Non fraintenermi. A me XP piace, e piace parecchio.
Ma una cosa che credo d'aver imparato finora e' che (come dicono gli
inglesi) 1) non ci sono silver bullets; 2) le persone contano in genere
piu' dei metodi. Quindi, siccome a me XP pare piu' o meno "equivalente",
come livello di difficolta' di applicazione (nota il "di applicazione"),
ad un approccio basato su UML (e se qui non sei d'accordo, possiamo
discutere i perche' :), ci andrei cauto ad affermare cose cosi'
apoditticamente.
D'altro canto, posso capire: la mia ora come evangelizzatore e'
probabilmente passata. :-)
>>In estrema sintesi, i creatori di UML non sono esattamente imbecilli
>>(se non altro, lo dimostra il fatto che vivono - e bene - di pura
>>consulenza
>>:).
>>
>Nessuno sta dicendo questo, assolutamente, per nulla!
Chi ha scritto il <quote> sopra, lo diceva, sia pure in via eufemistica.
:-)
>[...]
>Il punto e' che l'anticipazione porta con se' complessita', e
>questa non e' una strada da seguire.
Imho, la complessita' da evitare e' la complessita' *inutile*.
Ci sono casi (e piu' d'uno :) in cui l'anticipazione mi ha salvato
il sedere. Tutto sta nel rapporto costo/incremento di complessita',
e io tendo a rifuggere da tutte le affermazioni che non hanno
condizioni al contorno. :-)
Come ho gia' detto, XP (o meglio, quella regola) e' un'ottima cura
per chi fa overdesign - che e' un vizio di gioventu' del 99% dei
progettisti OO.
Ma anticipazione != overdesign. Imho, almeno. :-)
>Questo e' vero. Quando posso, io cerco di spiegare quali sono i vantaggi
>di XP e di un approccio iterativo incrementale stretto ìn vece di
>approcci + classici.
Lo so, ed e' per questo che ci parlo volentieri, con te - affina le idee.
:-) Ma *quanti* ne incontri di gente cosi' nel mondo IT commerciale?
>Basta farrgli svuotare la tazza :-) e riempirla nuovamente. Certo e' che
>se "fin da piccoli" gli dicono che OO e' un buon metodo per modellare la
>realta'... vedi tu.
E chi ti dice che il software debba modellare la realta'? :-)
Un software deve essere ben specificato, prodotto entro tempo e budget,
dopodiche' funzionare in modo ragionevolmente robusto.
OO e' uno strumento (affinamento di altri strumenti precedenti) che
permette di realizzare questi obiettivi per problemi entro un certo grado
di complessita'. Il fatto e' che anche se semplifica molte cose, continua
a richiedere testa e compentenza. 'sto fatto, ahime', e' condiviso da
UML/RUP, XP o qualunque altro approccio.
Il modo piu' semplice di fare cose complesse puo' non essere affatto
semplice (questa, in vari rigiramenti, e' un'altra fav of mine :-)
>Io sto ora mettendo un po' a posto la casa e sto
>dando il bianco: ho provato *personalmente* a mettermi davanti al muro
>dicendogli "muro, dipingiti!" ma non funziona! Neanche con i libri,
>"libro apriti a pagina X!". Eppure nel software funziona cosi.. mah!
>Vorra' dire qualcosa? :-D
Naturalmente: che ne' il muro ne il libro sono sistemi software. :-)
>Questo lo facevo anche io, ma purtroppo non e' sempre sufficiente a
>reggere il cambiamento. I requisiti cambiano, il cliente cambia idea, e
>se non hai flessibilita' nel contratto che stipuli non riesci a
>gestirlo. Anche se sei un mago del software.
Io parlavo, seppur scherzosamente, *proprio* di queste situazioni.
Ed e' proprio li' che un po' d'anticipazione aiuta.
>Attualmente secondo me il modo migliore di sviluppare software e'
>affittare il team presso il cliente, con il cliente che ti lavora a
>fianco, cosi' e' il massimo. Se potessi tornare indietro di un tre anni,
>almeno un progetto sarebbe andato oggi sulla via giusta.
Vero, ma *quando* e' possibile? Se riesci ad avere un project manager
da parte del cliente e' gia' ottimo - e di solito *non* e', per ovvi
motivi, la persona piu' competente nell'area; o se lo e' non ha molto
tempo, per il buon motivo che la persona piu' competente nell'area di
solito *lavora* nell'area. E dove li metti gli utenti, i manutentori, i
programmatori interni, che deve installare, gli impiegati, etc? :-)
Se domandi ad una matricola di Informatica se per lui e' importante
avere il cliente che valida quello che stai facendo *mentre* lo stai
facendo, nove su dieci ti risponde si'. Il problema e' farlo - che e'
un problema che XP condivide con qualunque altro approccio.
>Tutto sta a vedere cosa
>>intendi per "semplice". :-)
>>
>Non complicato :-D
Eheh, magari fosse cosi' semplice. :-)
Cose non complicate per me, per esempio, sono intricatissime per il mio
programmatore piu' junior. E cose semplicissime per un fisico nucleare
sono incomprensibili per me. :-)
>Potrei dire cbe una soluzione e' semplice se non anticipa nulla o se
>chiunque nel tuo team semplicemente leggendo il codice ne comprende
>perfettamente il funzionamento.
Appunto: semplicita' dipendente da chi legge. Hm. ;-)
>
>Comunque Beck dice che il codice e' semplice quando:
>- fa funzionare tutti i test
>- esprime tutte le idee che tu hai bisogno di esprimere
>- non contiene duplicazioni
>- ha il numero minimo di classi e metodi
Il che (e Beck e' il primo a dirlo, tant'evvero che ci sta scrivendo un
libro sopra, sull'applicazione di XP) vuol dir poco o nulla.
Il problema e' - ovviamente - nell'"esprime tutte le idee etc". :-)
>>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'.
>>
>L'industria siamo noi :-)
Questo vorrei fosse vero. Sarei, almeno, meno povero di quanto sono. :-)
Bruno Bossola
>>lightweight, ma tieni conto che lui era (e'?) un accanito sostenitori
>>dei generatori di applicazioni, i mitici 4GL, dove la complessita' viene
>>risolta con complessita. Esattamente l'inverso di quello cui tende XP,
>>che usa invece la semplicita'.
>
>Intendevo solo dire che waterfall e' state of the art anni '70; e lo
>state of the art *e'* cambiato molto prima di oggi.
>
tiro' fuori il waterfall.
>E' la penetrazione nell'industria che e' una cosa diversa.
>
Questo di sicuro, io il waterfall l'ho usato alla go-go fino al 1996 nella mia azienda
(Atos), una software house per la quale il software e' il core business
>>BLUC? DLUC? SBLUB? :-)
>
>Scusa, business-level UC e development-level UC. :-)
>
Niente, io lo so ma altri possono non saperlo :-D
Visto che ci seguono cosi' appassionatamente :-)))
>>>O il RAD di IBM (e Rambaugh li' lavorava).
>>Gia'. A che serve? (eh eh eh) (Ah, sto parlando del RAD, ovviamente :-D)
>
>Ad illustrare che waterfall era, gia' 15 anni fa, ben lungi dall'essere
>pensato come il meglio possibile. :-)
>
Questo in linea teorica e' possibile: da un punto di vista pratico fino al 94 almeno il
waterfall era usato nella stragrande maggioranza delle software factory
>>Mi spiace, io non vedo UML come condizione per arrivare a XP.
>
>Non parlavo di UML, ma di modello iterativo/incrementale.
>E di progresso storico, non di condizioni. :-)
>
Okay.
>>Per
>>arrivare a XP ci vuole esperienza, un sacco di esperienza: sicuramente
>>coloro che hanno contribuito a sviluppare UML hanno contribuito, anche
>>se non direttamente, allo sviluppo di XP. Sicuramente un sacco di
>>persone che non hanno contribuito a UML hanno contribuito a XP.
>>Semplicemente con l'esperienza.
>
>...
>
>>No, guarda che non ci capiamo, non sto assolutamente criticando UML o le
>>persone che ci stanno dietro, stop!,
>
>Io rispondevo a chi (forse Michele) affermava che
>
><quote>
>"Il motivo e' che UML e' stato disegnato da anticipazionisti, persone
>convinte che realizzare un sistema software sia analogo a realizzare
>un ponte su un fiume."
></quote>
>
>Altro non so. :-)
>
Ah, okay, questa e' una mia provocazione, allora in effetti e' corretto. E la penso cosi,
ovvero che UML e' stato disegnato da anticipazionisti. Sono stato forse forte nel
paragone, ma il succo e' quello:
- Anticipazione == complessita' non necessaria.
- Ingengeria del Software != Ingengeria Civile.
- Diagrammi UML != Progetto ponte.
Ma questo non vale solo per la granurarita' di un "ponte", ma per qualsiasi suo pezzo,
fino ad arrivare ad un accoppiamento vite-bullone. Forse si puo' fare qualcosa per il
bullone, ma ormai sei cosi' vicino che tanto vale realizzarlo direttamente. Mi segui?
I processi non lightweight promossi attualmente (i.e. RUP) applicano si' un approccio
iterativo incrementale, ma non stretto a sufficienza. Perche' se lo stringessero a
sufficienza. tutti quei bei documenti che il processo *deve* produrre, non servirebbero a
niente. E i nostri amici non venderebbero fior di tool e case, compresi quelli di rountrip
diagramma - codice che tu sembri apprezzare.
>>non voglio dare ad intendere
>>questo. Semplicemente dico che hanno proposto (alcuni propongono ancora)
>>un approccio allo sviluppo del software che produce risultati inferiori
>>a quelli che puoi produrre usando XP.
>
>Non fraintenermi. A me XP piace, e piace parecchio.
>
>Ma una cosa che credo d'aver imparato finora e' che (come dicono gli
>inglesi) 1) non ci sono silver bullets; 2) le persone contano in genere
>piu' dei metodi. >
>
Certo, d'accordo sia su 1) che su 2). Io semplicemente sostengo che 1) XP e' attualmente
il metodo migliore che ci sia in circolazione (*attualmente*) e che 2) XP funziona
proprio' perche' si basa sulle persone.
>Quindi, siccome a me XP pare piu' o meno "equivalente",
>come livello di difficolta' di applicazione (nota il "di applicazione"),
>ad un approccio basato su UML (e se qui non sei d'accordo, possiamo
>discutere i perche' :), ci andrei cauto ad affermare cose cosi'...
>
Beh, non ho mai sostenuto che XP fosse facile da applicare, anzi, e' *molto* difficile da
applicare (o implementare). In particolare esso richiede uno sforzo gigantesco sulle
persone, che devono essere formate come team: molto deve essere speso nelle dinamiche di
interrelazione fra le persone, che devono essere in grado di parlarsi e capirsi, evitando
frizioni. E poi c'e' tutto il reskilling. No, XP non e' facile. Fa paura. Pensare di
abbandonarsi solo al codice. Richiede disciplina. Tanta. Guarda che probabilmente e' molto
piu' facile affidarsi a RUP.
>
>...apoditticamente.
>
Uhm.. apoditticamente? disarcivescontantinopolizzantemente? Vedi, anche dalle tue parole
traspare una complessita' non necessaria: dal fatto che usi sigle, parole d'uso non troppo
comune... :-)
La semplicita' e' la chiave di tutto.
>D'altro canto, posso capire: la mia ora come evangelizzatore e'
>probabilmente passata. :-)
>
Addirittura! No, tu avrai sempre un sacco da dire. E' solo che il campo e' vasto, e le
opinioni sono tante!
>>>In estrema sintesi, i creatori di UML non sono esattamente imbecilli
>>>(se non altro, lo dimostra il fatto che vivono - e bene - di pura
>>>consulenza
>>>:).
>>>
>>Nessuno sta dicendo questo, assolutamente, per nulla!
>
>Chi ha scritto il <quote> sopra, lo diceva, sia pure in via eufemistica.
>:-)
>
Okay, allora anche io prima :-)
><quote>
>"Il motivo e' che UML e' stato disegnato da anticipazionisti, persone
>convinte che realizzare un sistema software sia analogo a realizzare
>un ponte su un fiume."
></quote>
>>[...]
>>Il punto e' che l'anticipazione porta con se' complessita', e
>>questa non e' una strada da seguire.
>
>Imho, la complessita' da evitare e' la complessita' *inutile*.
>Ci sono casi (e piu' d'uno :) in cui l'anticipazione mi ha salvato
>il sedere. Tutto sta nel rapporto costo/incremento di complessita',
>e io tendo a rifuggere da tutte le affermazioni che non hanno
>condizioni al contorno. :-)
>
[snip]
>
>Ma anticipazione != overdesign. Imho, almeno. :-)
>
[snip]
>>Questo lo facevo anche io, ma purtroppo non e' sempre sufficiente a
>>reggere il cambiamento. I requisiti cambiano, il cliente cambia idea, e
>>se non hai flessibilita' nel contratto che stipuli non riesci a
>>gestirlo. Anche se sei un mago del software.
>
>Io parlavo, seppur scherzosamente, *proprio* di queste situazioni.
>Ed e' proprio li' che un po' d'anticipazione aiuta.
>
Interessante. Spiegami, comn parole semplici pero', in quale caso la complessita' e
l'anticipazione sono utili. Svisceriamo l'argomento e vediamo se riesco a farti passare
dalla mia parte :-)
>Come ho gia' detto, XP (o meglio, quella regola) e' un'ottima cura
>per chi fa overdesign - che e' un vizio di gioventu' del 99% dei
>progettisti OO.
>
No, mi spiace. XP non e' una cura, e' un metodo da applicare, con rigorosa disciplina.
Cosi' come la spacci tu sembra una medicina :-D (o una droga!)
>>Questo e' vero. Quando posso, io cerco di spiegare quali sono i vantaggi
>>di XP e di un approccio iterativo incrementale stretto ìn vece di
>>approcci + classici.
>
>Lo so, ed e' per questo che ci parlo volentieri, con te - affina le idee.
>:-) Ma *quanti* ne incontri di gente cosi' nel mondo IT commerciale?
>
Beh, qualcuno l'ho trovato. Ad esempio i clienti si convincono velocemente. A me e'
successo qui in banca, dove lavoro ora. Il nostro cliente e' rimasto estremamente colpito
dalla rapidita' con cui abbiamo consegnato, e da come lui stesso ha "scoperto" delle cose
che da solo non aviva capito. Se hai tempo leggiti il paper che abbiamo presentato ad
XP2001, lo trovi (con allegati anche dei dati ed un articolo + completo) su www.xplabs.com
>>Basta farrgli svuotare la tazza :-) e riempirla nuovamente. Certo e' che
>>se "fin da piccoli" gli dicono che OO e' un buon metodo per modellare la
>>realta'... vedi tu.
>
>E chi ti dice che il software debba modellare la realta'? :-)
>
In molti lo dicono ancora adesso, credimi. Tu fai parte della banda? Chiedi al libro di
aprirsi alla pagina X :-D?
>Un software deve essere ben specificato, prodotto entro tempo e budget,
>dopodiche' funzionare in modo ragionevolmente robusto.
>
>OO e' uno strumento (affinamento di altri strumenti precedenti) che
>permette di realizzare questi obiettivi per problemi entro un certo grado
>di complessita'. Il fatto e' che anche se semplifica molte cose, continua
>a richiedere testa e compentenza. 'sto fatto, ahime', e' condiviso da
>UML/RUP, XP o qualunque altro approccio.
>
>Il modo piu' semplice di fare cose complesse puo' non essere affatto
>semplice (questa, in vari rigiramenti, e' un'altra fav of mine :-)
>
Si, pero' ci sono approcci che introducono complessita' artificiale (== anticipazione) e
altri che non lo fanno.
>>Io sto ora mettendo un po' a posto la casa e sto
>>dando il bianco: ho provato *personalmente* a mettermi davanti al muro
>>dicendogli "muro, dipingiti!" ma non funziona! Neanche con i libri,
>>"libro apriti a pagina X!". Eppure nel software funziona cosi.. mah!
>>Vorra' dire qualcosa? :-D
>
>Naturalmente: che ne' il muro ne il libro sono sistemi software. :-)
>
Gia'! Ma allora object oriented non modella la realta', altrimenti nella realta' si
farebbe esattamente cosi!
>>Attualmente secondo me il modo migliore di sviluppare software e'
>>affittare il team presso il cliente, con il cliente che ti lavora a
>>fianco, cosi' e' il massimo. Se potessi tornare indietro di un tre anni,
>>almeno un progetto sarebbe andato oggi sulla via giusta.
>
>Vero, ma *quando* e' possibile? Se riesci ad avere un project manager
>da parte del cliente e' gia' ottimo - e di solito *non* e', per ovvi
>motivi, la persona piu' competente nell'area; o se lo e' non ha molto
>tempo, per il buon motivo che la persona piu' competente nell'area di
>solito *lavora* nell'area. E dove li metti gli utenti, i manutentori, i
>programmatori interni, che deve installare, gli impiegati, etc? :-)
>
Ti assicuro che e' possibile, anche se non e' facile. Leggi anche sotto altre
considerazioni.
>Se domandi ad una matricola di Informatica se per lui e' importante
>avere il cliente che valida quello che stai facendo *mentre* lo stai
>facendo, nove su dieci ti risponde si'. Il problema e' farlo - che e'
>un problema che XP condivide con qualunque altro approccio.
>
Se domandi a qualunque dipendente Atos, Sesam, GSA (per citare delle realta' di software
factory che conosco) se volessero avere il cliente a fianco, ti chiederebbero se sei matto
:-) Loro *non* vogliono avere il cliente a fianco, perche' il cliente potrebbe cambiare
idea, potrebbe farti fare d'autorita' delle cose che non erano previste, puo' farti fare
piccoli ed infidi cambiamenti sui requisiti che ti fanno incasinare e perdere settimane di
tempo.
In XP invece e' esattamente il contrario: se il cliente cambia idea, noi siamo contenti. E
non perdiamo tempo. Embrace change!
>Cose non complicate per me, per esempio, sono intricatissime per il mio
>programmatore piu' junior. E cose semplicissime per un fisico nucleare
>sono incomprensibili per me. :-)
>
Beh, nel tuo caso c'e' un problema nel team: se tu applicassi XP questi problemi non li
incontreresti. Se vuoi approfondiamo.
>>Potrei dire cbe una soluzione e' semplice se non anticipa nulla o se
>>chiunque nel tuo team semplicemente leggendo il codice ne comprende
>>perfettamente il funzionamento.
>
>Appunto: semplicita' dipendente da chi legge. Hm. ;-)
>
Si, ma chi legge fa parte di un team. Non si parla di persone "sconnesse" fra di loro
(l'analista, il designer, il sw-architect, il programmatore genialoide, il programmatore
sgualfo, ecc.ecc) ma di un team.
>>Comunque Beck dice che il codice e' semplice quando:
>>- fa funzionare tutti i test
>>- esprime tutte le idee che tu hai bisogno di esprimere
>>- non contiene duplicazioni
>>- ha il numero minimo di classi e metodi
>
>Il che (e Beck e' il primo a dirlo, tant'evvero che ci sta scrivendo un
>libro sopra, sull'applicazione di XP) vuol dir poco o nulla.
>
Interessante il fatto che tu dica "Beck e' il primo a dirlo". Sicuro? A me non risulta. Ma
se mi dai retta lasciamo in pace Kent e rimaniamo fra noi.
>Il problema e' - ovviamente - nell'"esprime tutte le idee etc". :-)
Tutti quegli aspetti sono problematici da definire, se ci pensi, e c'e' un unica persona
che ti puo' aiutare a chiarirli, e, paradossalmente, e' il cliente. E' lui che ti guida
nello sviluppo del tuo software, non sei *mai* tu che guidi lui.
>>>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'.
>>>
>>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?
ugo landini
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
Cristiano Sadun
>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...
Vietato ritirarsi! Piu' opinioni ci sono, piu' e' divertente e piu'
s'impara. :-)
ugo landini
uL
Bruno Bossola
>introduttivo decente.... l'ideale sarebbe comunque il libro di Beck, XP eXplained, ma ci
>sono anche un bel po' di risorse in rete, ovviamente tutte in inglese (per ora :-D)
>
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.
Bruno Bossola
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
ugo landini
> 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
Cristiano Sadun
>Uhm... 1970? No, allora era *appena* uscito l'articolo di Royce da cui
>poi qualche furbo tiro' fuori il waterfall.
State of the art, appunto: il picco di competenza nell'intera area,
accademia+IT commerciale+chiunquenonsiaclassifcabilenelledue. :-)
>Questo di sicuro, io il waterfall l'ho usato alla go-go fino al 1996
>nella mia azienda (Atos), una software house per la quale il software e'
>il core business
Cvd. :) Io sono stato fortunato. Ho incontrato 'sta cosa dell'object
oriented (che di per se non c'entra, ma evidenzia i limiti dell'approccio
standard, e all'epoca si parlava di OOP e punto :) nel '90, per
curiosita', (mentre io e un altro amico pazzoide scrivevamo circa 200KLOC
di codice C per l'esame di sistemi, dato che il progetto ufficiale era
troppo banale :) e circa due anni dopo mi capito' sottomano, in
dipartimento, un articolo di Jacobson su quello che poi sarebbe diventato
objectory. Siccome facevo software per pagarmi in parte l'universita', mi
interessai - e scoprii OMT, Booch, Martin, etc. Negli anni successivi,
quando non lavoravo come freelance ma ero in qualche struttura
organzzata, mi dannavo l'anima per capire perche' cose ovvie *non*
venissero nemmeno prese in considerazione e 'sto dannato
analisi-design-codifica-test, che ovviamente *non* funziona su cicli
larghi, venisse tenuto in tanta considerazione - ma ero gia' vaccinato.
:-)
>Niente, io lo so ma altri possono non saperlo :-D
>Visto che ci seguono cosi' appassionatamente :-)))
Appunto. Dubito ci siano anche i famosi 25 lettori. :-)
>>Ad illustrare che waterfall era, gia' 15 anni fa, ben lungi dall'essere
>>pensato come il meglio possibile. :-)
>>
>Questo in linea teorica e' possibile: da un punto di vista pratico fino
>al 94 almeno il waterfall era usato nella stragrande maggioranza delle
>software factory
E' esattamente il mio punto: un conto e' cosa "sa" (e fa, o prova a fare)
chi e' informato o interessato di s/e; un conto cosa fa l'industria IT,
che per la gran parte appare composta da gente che se ne interessa poco,
ed e' piu' interessata a sapere qual'e' il nome del metodo Pippo per
ottenere il risultato Pluto dalla libreria PincoPallo, e morta li'. :-)
>Ah, okay, questa e' una mia provocazione, allora in effetti e' corretto.
:-D
>E la penso cosi, ovvero che UML e' stato disegnato da anticipazionisti.
>Sono stato forse forte nel paragone, ma il succo e' quello:
>- Anticipazione == complessita' non necessaria.
>- Ingengeria del Software != Ingengeria Civile.
>- Diagrammi UML != Progetto ponte.
Sulla seconda, sono d'accordissimo, ma figurati che c'e' chi sostiene (e
con ragioni a cui a malincuore devo dare qualche valore) che non _esiste_
qualcosa chiamata ingegneria del software. :-)
Sulla terza, ovviamente, e' quel che vo dicendo. :-)
Sulla prima, come ho detto, non sono d'accordo. Anzi.
Nella mia esperienza, un po' d'anticipazione aiuta ed aumenta
l'efficienza nella codifica successiva, e l'aumenta parecchio. Troppa
anticipazione e' overdesign. La differenza la fa il costo stimato di
codifica, la diminuzione in leggibilita' e manutenibilita', la
probabilita' stimata d'uso, in milkshake con i vantaggi (risparmi) futuri
stimati, il tutto (essenziale) commisurato ad una stima dell'abilita' del
team.
Il grado di sensibilita' su 'ste cose e' cio' che distingue un buon
designer da uno cattivo (o semplicemente senza troppa esperienza, o
superentusiasta).
Ma (e devo a Carlo Pescio d'avermelo mostrato :) invece di usare
vocaboli, facciamo un paio d'esempi, cosi' magari ci capiamo meglio.
Uno, e' un classico: l'uso di factory a design time per *denotare* il
fatto che la scelta di una certa implementazione e' soggetto a condizioni
al contorno esterne al codice. Per dire, qui abbiamo appena finito di
realizzare un database XML in grado di permettere accesso remoto ai nodi
(sotto forma di DOM), minimizzare network calls e scalabile su un numero
arbitrario di nodi (l'ultimo test ha caricato 200Mb di "file" XML :-). La
cosa, supportata da un database (relazionale, ad oggetti, etc). Ora, la
prima implementazione risultava avere un bottleneck di performance sulla
gestione di questo database per grandi volumi. (il motivo per cui tale
test *non* e' stato possibile farlo prima e' esattamente una di quelle
combinazioni cliente capriccioso/hardware mancante/risorse in vacanza
che capitano nei progetti fuori dai paper di ricerca :-)
Siccome 'sto oggetto manager era prodotto da una factory, abbiamo
modificato l'implementazione, sostituita alla vecchia, e voila',
performance alle stelle. Il tutto in due giorni (perche' la deadline?
Perche' il mio CEO ha dato un'occhiata ai risultati pre-system test e ha
deciso che o la cosa funzionava entro mercoledi', o si buttava via tutto
e si stava sull'implementazione precedente: tipico comportamento da
"utente" :).
Seguendo un approccio non-anticipazionista, il resto del sistema (e si
parla di migliaia di linee di codice) sarebbe uscito con riferimenti
diretti alla vecchia implementazione, e sarebbe stato parecchio piu'
difficile fare la stessa cosa *in cosi' poco tempo*. Non perche' - nota
bene - non sia possibile codice senza factory e piuttosto indipendente
dall'implementazione... ma perche' il programmatore medio, bravo e
competente, tende a stare concentrato su cio' che sta implementando, e
non ne trovi molti che siano in grado di risolvere efficacemente il
problema sottomano *e* mantenere generalita' senza fatica.
E io non ho tempo (e la voglia ;-) di leggere il codice di tutti, e le
peer review, ahime', hanno il difetto di dipendere da competenze e
interesse dei peers. :-)
Mettere li' una factory non costa molto (a livello di implementazione,
un'interfaccia, una classe in piu', l'uso di un metodo invece di una new,
un private sul costruttore e qualche cianfrusaglia); certo, c'e' la
difficolta' di lettura, e per un programmatore junior viene fuori
indubbiamente codice piu' complesso da leggere: hai presente, le domande
qui su icj, "come si usa Runtime?" etc? Ma il programmatore junior impara
(i pattern, ad esempio) e dopo un po' non e' piu' junior; e un po'
d'anticipazione (anticipare la possibilita' che una prima implementazione
possa essere funzionalmente valida ma non abbastanza efficiente) ti salva
il sedere.
Secondo esempio, sempre dallo stesso progetto. Un cliente ci ha chiesto,
settimana scorsa, di implementare il logging del sistema su SNMP (di cui
la XML storage di cui sopra fa parte).
Ora, circa sei mesi fa, quando abbiamo progettato un sistema di log, il
problema era "fare log", principalmente per gli sviluppatori, su console
o al piu' su file o system log.
Ancora una volta, l'approccio "semplice" sarebbe stato di realizzare una
cosina minima e bon - magari System.out. L'approccio (leggermente)
anticipazionista sta nel valutare la probabilita' che la destinazione del
log possa cambiare, e il costo di un piccolo framework che, usato per
default, si comporta nel modo atteso da un programmatore/ sysadm che
vuole vedere che diavolo e' successo... *ma che puo' essere esteso* in
certe direzioni facilmente. Ti diro', io non pensavo minimamente a SNMP -
piu' ad integrazioni con log esistenti in altri application server. Per
farla breve, il plugin che realizza traps SNMP e permette di integrare il
sistema in una SNMP console e' finito e unit-tested oggi.
Certo, il costo iniziale e' stato di tre/quattro giorni di codifica. Il
sistema di log *e'* piu' intricato di un System.out - anche se _usandolo_
non si vede (questa e' in genere la firma dei lavori del mio gruppo :-).
Ma adesso posso stare qui tranquillo e scrivere questa risposta invece di
dannarmi l'anima - perche' tutto il riusabile per realizzare questa
funzionalita' l'abbiamo riusato, e la facility per SNMP e' in via di
testing. Tre giorni dopo la richiesta.
>
>Ma questo non vale solo per la granurarita' di un "ponte", ma per
>qualsiasi suo pezzo, fino ad arrivare ad un accoppiamento vite-bullone.
>Forse si puo' fare qualcosa per il bullone, ma ormai sei cosi' vicino
>che tanto vale realizzarlo direttamente. Mi segui? I processi non
>lightweight promossi attualmente (i.e. RUP) applicano si' un approccio
>iterativo incrementale, ma non stretto a sufficienza.
Questo e' vero - una delle cose che apprezzo maggiormente di XP e' il
ciclo di integrazione stretto. Pero' tieni presente che le iterazioni
del I/I sono *macro* iterazioni: in genere su vari mesi. Il mio approccio
e' sempre stato di eseguire microiterazioni molto ravvicinate; ho
visto altra gente usare una sorta di waterfall per le microiterazioni,
col risultato che possono passare settimane con il processo che
va per i cavoli suoi senza controllo.
E il trucco nell'usare UML e' tutto nel documentare cose che *non*
sono evidenti. Per quelle evidenti, un disegno e' una perdita di tempo.
>Perche' se lo
>stringessero a sufficienza. tutti quei bei documenti che il processo
>*deve* produrre, non servirebbero a niente.
E' qui che ti sbagli. :-)
Come avevo accennato, UML (o qualunque linguaggio grafico) e' un
linguaggio vivo, e va usato come tale.
Non (solo) per documentare *a posteriori*, ma per *comunicare* il sistema
mentre e' in via di sviluppo - come ho vagamente descritto in un
post precedente. Per esempio, io uso diagrammi che non sono UML e li
trovo utilissimi - reti di Petri, (T/E semplificate) - e non
trovo gli activity diagram altrettanto efficaci.
Per dire, un sequence diagram e' per me - e per il mio gruppo -
infinitamente piu' chiaro (per *discutere* il problema e la soluzione)
dell'equivalente in codice. Ci permette di concentrarci sugli aspetti
essenziali, e verificare idee e design *velocemente*.
Io sono, ahime', ossessionato dall'efficienza (essendo fondamentalmente
pigro).
La documentazione in fase post- e', in questo modo, gratis.
> E i nostri amici non
>venderebbero fior di tool e case, compresi quelli di rountrip diagramma
>- codice che tu sembri apprezzare.
Per esempio, io non apprezzo piu' Rational Rose. Lo apprezzavo prima,
perche era sostanzialmente l'unico, e vedevo le potenzialita'. Ma ora
e' (almeno, l'ultima versione che ho provato) di gran lunga superato.
Togheter (grazie Ugo :-) e StructureBuilder sono promettenti.
>>Ma una cosa che credo d'aver imparato finora e' che (come dicono gli
>>inglesi) 1) non ci sono silver bullets; 2) le persone contano in genere
>>piu' dei metodi. >
>>
>Certo, d'accordo sia su 1) che su 2). Io semplicemente sostengo che 1)
>XP e' attualmente il metodo migliore che ci sia in circolazione
>(*attualmente*) e che 2) XP funziona proprio' perche' si basa sulle
>persone.
1) Io sono piu' prudente, in forza di 2). :-)
2) In che senso gli altri metodi *non* si baserebbero sulle persone?
Se uno si limita a riempire boilerplates, fallisce qualunque metodo
stia applicando.
>Uhm.. apoditticamente? disarcivescontantinopolizzantemente? Vedi, anche
>dalle tue parole traspare una complessita' non necessaria: dal fatto che
>usi sigle, parole d'uso non troppo comune... :-)
Ridendo.. "apodittico" non e' d'uso comune - in una _discussione_ ?
Okay, okay, chiedo venia. ;-)
Le sigle, le uso con in testa la persona a cui sto parlando.. e infatti
tu le sapevi, nevvero? ;-) Eppoi qui si parla di informatica, mica di
melanzane. Che, se parli di matematica, non dici mai "integrale"? ;-)
Se uno le sigle non le capisce (io per primo), domanda, o RTFM, che
fa sempre bene. :-)
>Addirittura! No, tu avrai sempre un sacco da dire. E' solo che il campo
>e' vasto, e le opinioni sono tante!
E meno male, senno' ci si annoia.
>Interessante. Spiegami, comn parole semplici pero', in quale caso la
>complessita' e l'anticipazione sono utili. Svisceriamo l'argomento e
>vediamo se riesco a farti passare dalla mia parte :-)
Hm, vuoi farmi scrivere L'Incredibile E Inarrivabile Teoria Del Software
Di Cristiano Sadun? (ridendo... :-) Gli ingredienti gli ho nominati
sopra, e gli esempi pure:
(ah, le parole sono le piu' semplici possibile.. come dicevo, non
necessariamente questo implica siano *semplici* :-)
1) *leggero* aumento di complessita'.
*Leggero* si valuta in parte in modo assoluto (usando qualche
metrica ad hoc, o l'occhio dell'esperienza :) _e_ nei confronti
delle capacita' di chi (si stima) sara' il lettore.
Ovviamente piu' tali stime sono imprecise, piu' e' difficile trovare
l'equilibrio, nel qual caso, nel dubbio, e' meglio eliminare
complessita' che aggiungerla. Il caso piu' difficile e' un framework,
in cui l'audience attesa puo' variare dal guru al programmatore
junior. Il caso piu' semplice e' un progetto applicativo con un team
stabile nel tempo di cui si conoscono capacita' e debolezze.
2) Ragionevolezza dei benefici/fuoco sugli obiettivi
Evitare il complesso di superman: se si parte con l'idea di fare
una moka, non si deve finire a fare un boiler perche "c'e' caso
che..". *Anche* se sarebbe possibile fare un boiler, io faccio e
faccio fare una moka.
Il punto e' che ad un programmatore/designer entusiasta *piace*
programmare e disegnare software. C'e' (Pirsig insegna :-)
un'eleganza e un piacere estetico nel mettere insieme codice che
fa quel che deve fare, e poi di piu', e poi di piu', eccetera.
Se 'sta cosa non si disciplina, il risultato e' overdesign.
Per fare una stima corretta e' necessario *uscire* dal punto di
vista "puro software" e tenere presente l'intero scenario - compreso
il punto di vista del CEO a cui non frega un accidente del software
di per se', ma deve fare i suoi numeri ogni trimestre... e che
ha _perfettamente ragione_ a pensarla in questo modo.
3) costo *basso* in rapporto ai benefici stimati
Il costo dell'anticipazione, in termini di giorni/uomo, dev'essere
ragionevole, in rapporto a
- probabilita' d'uso futuro effettivo (stimata)
- impatto sulla semplicita' d'uso _presente_ :)
- impatto sulle performance
Lo schedule del progetto aiuta a dare un'idea di "ragionevole": se
il progetto e' di due anni, una settimana o due sono ragionevoli.
Se e' di due mesi, due giorni sono ragionevoli.
Nota che il costo (di sviluppo) e' in generale dipendente dallo
sviluppatore. Un'anticipazione ragionevole se la scrivi tu puo'
non essere ragionevole se la scrivo io, se io sono piu' lento.
O se la deve mantenere un terzo.
>>Come ho gia' detto, XP (o meglio, quella regola) e' un'ottima cura
>>per chi fa overdesign - che e' un vizio di gioventu' del 99% dei
>>progettisti OO.
>>
>No, mi spiace. XP non e' una cura, e' un metodo da applicare, con
>rigorosa disciplina. Cosi' come la spacci tu sembra una medicina :-D (o
>una droga!)
Ma lo e'. :) Un sacco di gente ha (finalmente) cominciato a leggere
sugli oggetti, su UML, su s/e, sui metodi etc, si e' entusiasmata, e via
a over-disegnare. E' - imho - un passo comune a chiunque sia veramente
*appassionato*. O almeno a molti.
Ed ecco che arriva XP e dice "'mbecilli! Tutte 'ste cose non servono
ad una mazza, concentratevi sul fare quello che dovete fare!"
Una cura, appunto. :-) L'OO e' (come tutto il software) un gran bel
gioco.
>Beh, qualcuno l'ho trovato. Ad esempio i clienti si convincono
>velocemente. A me e' successo qui in banca, dove lavoro ora. Il nostro
>cliente e' rimasto estremamente colpito dalla rapidita' con cui abbiamo
>consegnato, e da come lui stesso ha "scoperto" delle cose che da solo
>non aviva capito. Se hai tempo leggiti il paper che abbiamo presentato
>ad XP2001, lo trovi (con allegati anche dei dati ed un articolo +
>completo) su www.xplabs.com
Sara' fatto. :-)
>>E chi ti dice che il software debba modellare la realta'? :-)
>>
>In molti lo dicono ancora adesso, credimi. Tu fai parte della banda?
No. Il software deve funzionare, e bene; ed essere facile da mantenere
ed estendere. In aggiunta, per me, dev'essere divertente da scrivere
e soddisfacente esteticamente (avere Qualita' :), e essere
costruito il piu' velocemente possibile, cosi' non mi preoccupo, e
ho tempo di uscire con qualche nuova norvegese o giocare a Diablo II. :-)
Tutto quanto mi aiuta a raggiungere questo obiettivo, lo uso.
L'OO mi aiuta. :-)
>Chiedi al libro di aprirsi alla pagina X :-D?
:-)
>Si, pero' ci sono approcci che introducono complessita' artificiale (==
>anticipazione) e altri che non lo fanno.
Ci sono approcci che _favoriscono_ complessita' artificiale se uno non
sa cosa sta facendo. Verissimo. XP non lo fa, o lo fa meno. Verissimo.
Anche guidare una Ferrari non e' come la Panda. Ci puoi andare piu'
veloce, ma se non sai che stai facendo e' piu' facile schiantarti.
(PS: la metafora e' stiracchiata: XP non e' una Panda. Ma c'intendiamo.
:-)
>Gia'! Ma allora object oriented non modella la realta', altrimenti nella
>realta' si farebbe esattamente cosi!
Come ho gia' detto, io non l'ho mai detto che OO modelli fedelmente la
realta'.
<modo pedante>
Giusto per la precisione, occhio alla terminologia: un modello non e'
necessariamente isomorfo al dominio modellato. Anche un programma pascal
modella il pezzo di realta' a cui si riferisce. Quel che intendi tu e' un
modello 1 a 1 (appunto isomorfo).
</modo pedante>
(scusa la pedanteria :)
>Ti assicuro che e' possibile, anche se non e' facile. Leggi anche sotto
>altre considerazioni.
Avere *tutti* on board *durante* lo sviluppo? Ecchecciai, un quartier
generale grosso come la lombardia? :-)
>Se domandi a qualunque dipendente Atos, Sesam, GSA (per citare delle
>realta' di software factory che conosco) se volessero avere il cliente a
>fianco, ti chiederebbero se sei matto
Probabile. :-) Forse perche' quelle software factory sono fatte da
persone diverse da uno studente del prim'anno di informatica (il quale,
in genere, e' almeno cosciente di _non_ saperle, tante cose :-)
>:-) Loro *non* vogliono avere il cliente a fianco, perche' il cliente
>:potrebbe cambiare
>idea, potrebbe farti fare d'autorita' delle cose che non erano previste,
>puo' farti fare piccoli ed infidi cambiamenti sui requisiti che ti fanno
>incasinare e perdere settimane di tempo.
>In XP invece e' esattamente il contrario: se il cliente cambia idea, noi
>siamo contenti. E non perdiamo tempo. Embrace change!
Ecco, io non sono X fino a quel punto. Come dicevo, sono interessato
anche ad altre cose, oltre al software. :-)
Io sono contento se un cliente _non_ mi cambia le specifiche. Quello che
so e' che quasi sempre un cliente le vuole cambiare, e uso le tecniche
note per far contento lui e rimanere contento io anche in quel caso. :-)
Occhio che - per contratto - io voglio (quando e' possibile) avere
la possibilita' di dire di no.
Altrimenti parti con un progetto per una bicicletta e il cliente ti puo'
chiedere un razzo. Il trucco e' mantenere continua sintonia col cliente
in modo che sia tu che lui sappiate che bicletta state facendo, e lui
*non* si aspetta un razzo, e sa perche'.
>Beh, nel tuo caso c'e' un problema nel team: se tu applicassi XP questi
>problemi non li incontreresti. Se vuoi approfondiamo.
Approfondiamo. :) Non vedo come sia un problema di team: io non ho tempo,
voglia e probabilmente capacita' per imparare a fare il fisico nucleare.
Se ho bisogno di fisica nucleare, *devo* chiedere ad un fisico nucleare,
e una volta che ce l'ho in team le parti di fisica nucleare saranno
piu' facili per lui che per me. XP o non XP.
Ancora, ti faccio notare che *non* mi sogno di parlare "contro" XP,
ma solo (adesso che abbiamo chiarito che chi ha disegnato UML non e'
un imbecille :^) mostrare come certi problemi non siano risolti e certe
tecniche siano applicabilissime (e migliorino il risultato) anche in
ambito XP.
>>>Potrei dire cbe una soluzione e' semplice se non anticipa nulla o se
>>>chiunque nel tuo team semplicemente leggendo il codice ne comprende
>>>perfettamente il funzionamento.
Ma allora fattorizzi tutto al minimo comune denominatore, il
programmatore junior. Che e' sempre li'. :-) Il trucco e' proprio il
contrario: esporlo a cose piu' complicate, aiutandolo a diventare
non-junior (il problema e' che poi se ne va per uno stipendio triplo - ma
non si puo' avere tutto dalla vita.. e soprendentemente, spesso non se ne
va :).
La *media* dei programmatori del team, dopo un certo periodo di
bootstrap, dovrebbe essere in grado di capire. Il che per me significa
che tutti devono masticare il/i linguaggio/i, le librerie principali,
qualche notazione grafica, qualche pattern e tecniche di base di OO, etc.
>Si, ma chi legge fa parte di un team. Non si parla di persone
>"sconnesse" fra di loro (l'analista, il designer, il sw-architect, il
>programmatore genialoide, il programmatore sgualfo, ecc.ecc) ma di un
>team.
Non so in che mondo vivi tu :) ma i team sono fatti da individui, ognuno
con sue caratteristiche e preferenze, e che restano individui. E magari
dove lavori tu e' facile trovare gente: ma qui no, tantomeno gente in
gamba.
Essi non sono "sconnessi": ma non perche' parte di un collettivo Borg, ma
perche' comunicano - e hanno gli strumenti per comunicare *anche* quando
le loro competenze sono profondamente diverse - che e' il caso comune.
UML e' uno di tali strumenti - che e' il motivo per cui lo uso.
*Se* per "sconnessi" intendi l'archietto che fa le specifiche e le passa
al designer che fa il disegno che passa al programmatore che implementa
che passa al tester che testa, il tutto senza comunicazione all'indietro
e feedback, questo e' waterfall - e non quello di cui sto parlando io.
:-)
>Interessante il fatto che tu dica "Beck e' il primo a dirlo". Sicuro?
Ricordo una discussione su comp.object (o comp.s.e.) in cui Martin o Beck
dicevano pressappoco quello. E che la descrizione di XP in "XP" :-)
non era sufficiente a chiarire la sua applicazione. Io lessi in fretta
sia riguardo a Chrysler che il libro l'anno scorso, e allora Beck ne
aveva in corso di scrittura uno, appunto, sulla applicazione di XP -
perche' i principi da soli si prestavano a mille interpretazioni.
>>Il problema e' - ovviamente - nell'"esprime tutte le idee etc". :-)
>Tutti quegli aspetti sono problematici da definire, se ci pensi, e c'e'
>un unica persona che ti puo' aiutare a chiarirli, e, paradossalmente, e'
>il cliente. E' lui che ti guida nello sviluppo del tuo software, non sei
>*mai* tu che guidi lui.
Temo di non essere d'accordo: col cliente, e' piu' un loop in feedback.
Ci sono mille situazioni in cui io posso proporre al cliente cambiamenti,
innovazioni e miglioramenti che *lui* non si sognerebbe - perche' io so
che sono fattibili, costano poco e (penso) siano d'aiuto.
Le informazioni, guide e stimoli viaggiano in due direzioni: questo
perche' un sistema software applicato ad un dominio applicativo
e' diverso da un sistema software o da un dominio applicativo da soli.
E l'arte di applicare concetti propri del software a concetti propri di
un dominio richiede, appunto, costante valutazione e feedback da
*entrambe* le parti. Anche un pilota d'aereo, in areoporto, e' guidato
dalla torre di controllo. :-)
Poi sta a lui (il cliente) decidere: ma un conto e' la decisone, un
conto la guida. Io sono guidato spessissimo da altri ragazzi nel mio
team, anche se prendo le decisioni e il _mio_ sedere e' quello che riceve
i calci se qualcosa non va bene.
Ancora: la lezione di XP - che io apprezzo per la *chiarezza* e l'enfasi
con cui cose gia' note sono espresse - e' che non si puo' chiudere il
cliente fuori, e l'analisi fatta inhouse e' pseudo-analisi (non mi
ricordo chi l'ha detto, ma e' tendenzialmente vero). Ma ancora, questo
e' del tutto indipendente da XP, se uno 'sta cosa la fa con qualunque
altro metodo (esistono progetti *di successo* eseguiti in waterfall.. :-)
>Vabbe' adesso non buttarti giu' cosi!
>Allora, lo scriviamo 'sto libro?
In effetti, ti volevo riproporre la cosa. :-)
Fabrizio Camera
>bbos...@hotmail.com (Bruno Bossola) wrote in
><3b810842.7634658@MI008IT-EFD01>:
[CUT]
>>Visto che ci seguono cosi' appassionatamente :-)))
>
>Appunto. Dubito ci siano anche i famosi 25 lettori. :-)
Almeno uno di sicuro: peccato non poter contribuire :-(, ma mi sto
documentando anche grazie a voi.
[CUT]
>cosi' non mi preoccupo, e
>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.
Bruno Bossola
>>
>>Appunto. Dubito ci siano anche i famosi 25 lettori. :-)
>
>Almeno uno di sicuro: peccato non poter contribuire :-(, ma mi sto
>documentando anche grazie a voi.
>
Okay, state sintonizzati, penso che in capo a un paio di giorni riusciro' a terminare la
risposta al post di Cristiano.
Bruno Bossola
po' a rispondere, non ho tutto sto tempo, e scusami se faro' un po' di tagli e condensero'
qualcosa: se si perde qualche parte essenziale, fammelo sapere.
>>- Anticipazione == complessita' non necessaria.
>>
>...non sono d'accordo. Anzi.
>
>Nella mia esperienza, un po' d'anticipazione aiuta ed aumenta
>l'efficienza nella codifica successiva, e l'aumenta parecchio. Troppa
>anticipazione e' overdesign. La differenza la fa il costo stimato di
>codifica, la diminuzione in leggibilita' e manutenibilita', la
>probabilita' stimata d'uso, in milkshake con i vantaggi (risparmi) futuri
>stimati, il tutto (essenziale) commisurato ad una stima dell'abilita' del team.
>
Come direbbe Francesco, "un minimo di anticipazione" (e lo direbbe col sorriso sulle
labbra, pronto ad affondare). Perche' pagare oggi per qualcosa che nel futuro non sei
neanche sicuro userai? [Segue sotto]
>Il grado di sensibilita' su 'ste cose e' cio' che distingue un buon designer
>da uno cattivo (o semplicemente senza troppa esperienza, o superentusiasta).
>
Quando anticipi tu stai cercando di individuare le aree in cui si verifichera' il
cambiamento: non e' facile, e non e' solo questione di capacita' di design. Bisogna anche
avere maturato un'esperienza significativa nel business e nel dominio. Questo non si puo'
sempre fare, e me ne sto accorgendo io che lavoro in una banca d'affari, in cui esistono
prodotti finanziari che neanche l'utente del sistema comprende appieno (pur facendoci un
sacco di soldi :-D)
Non e' meglio pagare domani per quello di cui domani sei sicuro avrai bisogno?
[Segue sotto]
>Uno, e' un classico: l'uso di factory a design time per *denotare* il
>fatto che la scelta di una certa implementazione e' soggetto a condizioni
>al contorno esterne al codice. Per dire, qui abbiamo appena finito di
>realizzare un database XML in grado di permettere accesso remoto ai nodi
>(sotto forma di DOM), minimizzare network calls e scalabile su un numero
>arbitrario di nodi (l'ultimo test ha caricato 200Mb di "file" XML :-). La
>cosa, supportata da un database (relazionale, ad oggetti, etc). Ora, la
>prima implementazione risultava avere un bottleneck di performance sulla
>gestione di questo database per grandi volumi.
>
L'esempio e' estremamente tecnico. Certo, le problematiche tecniche fanno certamente parte
di qualunque progetto ma i punti veramente critici di norma stanno nelle regole di
business. Oppure tu sei fra i fortunati che realizzano solamente infrastrutture
tecnologiche. Fammi un esempio con un problema di business.
>Siccome 'sto oggetto manager era prodotto da una factory, abbiamo
>modificato l'implementazione, sostituita alla vecchia, e voila',
>performance alle stelle. Il tutto in due giorni.
>
Questo perche' avendo anticipato sei riuscito a tenere basso il costo del cambiamento. Ma
non e' l'unico modo per farlo, e tenere basso il costo del cambiamento e' proprio uno
degli obbiettivi di XP. Con XP non e' necessario anticipare nulla: semplicemente il costo
del cambiamento e' _sempre_ basso. [vedi sotto]
>Seguendo un approccio non-anticipazionista, il resto del sistema (e si
>parla di migliaia di linee di codice) sarebbe uscito con riferimenti
>diretti alla vecchia implementazione, e sarebbe stato parecchio piu'
>difficile fare la stessa cosa *in cosi' poco tempo*. Non perche' - nota
>bene - non sia possibile codice senza factory e piuttosto indipendente
>dall'implementazione... ma perche' il programmatore medio, bravo e
>competente, tende a stare concentrato su cio' che sta implementando, e
>non ne trovi molti che siano in grado di risolvere efficacemente il
>problema sottomano *e* mantenere generalita' senza fatica.
>
E' giusto che ci sia questa concentrazione. E' sbagliato che non vengano applicati solidi
principi di OO e di design durante il refactoring. In XP si fa refactoring continuamnente
("Refactor Mercilessly") con l'obbiettivo di tenere la complessita bassa: in questo modo
e' sempre semplice apportare qualunque cambiamento in qualunque momento.
>E io non ho tempo (e la voglia ;-) di leggere il codice di tutti, e le
>peer review, ahime', hanno il difetto di dipendere da competenze e
>interesse dei peers. :-)
>
Tu non devi farlo (anche se puoi farlo se sei un coach) ma il team deve farlo. Se applichi
XP le code review ti vengono garantite automaticamente dal fatto che si lavora _sempre_ in
coppia ("Pair Programming"), le coppie si cambiano frequentemente e quindi il sorgente e'
conosciuto grosso modo da tutti ("Collective Ownership"), inoltre integrando
frequentemente le modifiche ("Continuous Integration", ogni 2/3 ore per intenderci) si
rivede sempre il codice degli altri.
>Mettere li' una factory non costa molto (a livello di implementazione,
>un'interfaccia, una classe in piu', l'uso di un metodo invece di una new,
>un private sul costruttore e qualche cianfrusaglia); certo, c'e' la
>difficolta' di lettura, e per un programmatore junior viene fuori
>indubbiamente codice piu' complesso da leggere: hai presente, le domande
>qui su icj, "come si usa Runtime?" etc? Ma il programmatore junior impara
>(i pattern, ad esempio) e dopo un po' non e' piu' junior; e un po'
>d'anticipazione (anticipare la possibilita' che una prima implementazione
>possa essere funzionalmente valida ma non abbastanza efficiente) ti salva
>il sedere.
>
Se usi XP un programmatore Junior e' sempre affiancato da uno piu' esperto durante tutte
le attivita' di sviluppo ("Pair Programming") e in poco tempo diventa esperto, anche
grazie al continuo avvicendarsi del proprio collaboratore e del codice su cui lavora
("Collective Ownership"). In questo modo i principi OO vengono a poco a poco assimilati,
in modo molto naturale, e il tuo programmatore cresce con il team.
>Secondo esempio, sempre dallo stesso progetto. Un cliente ci ha chiesto,
>settimana scorsa, di implementare il logging del sistema su SNMP (di cui
>la XML storage di cui sopra fa parte).
>
Di nuovo, un esempio estremamente tecnico, valgono le considerazioni di cui sopra.
>Ora, circa sei mesi fa, quando abbiamo progettato un sistema di log...[snip]
>
>Ancora una volta, l'approccio "semplice" sarebbe stato di realizzare una
>cosina minima e bon - magari System.out. L'approccio (leggerment)
>anticipazionista sta nel valutare la probabilita' che la destinazione del
>log possa cambiare, e il costo di un piccolo framework che, usato per
>default, si comporta nel modo atteso da un programmatore/ sysadm che
>vuole vedere che diavolo e' successo... *ma che puo' essere esteso* in
>certe direzioni facilmente... [snip]
>
>Certo, il costo iniziale e' stato di tre/quattro giorni di codifica. Il
>sistema di log *e'* piu' intricato di un System.out - anche se _usandolo_
>non si vede (questa e' in genere la firma dei lavori del mio gruppo :-).
>
>Ma adesso posso stare qui tranquillo e scrivere questa risposta invece di
>dannarmi l'anima - perche' tutto il riusabile per realizzare questa
>funzionalita' l'abbiamo riusato, e la facility per SNMP e' in via di
>testing. Tre giorni dopo la richiesta.
>
Quante altre anticipazioni non hanno centrato l'obbiettivo? E' possibile che _tutti_ i
punti in cui tu hai anticipato il cambiamento siano stati poi effettivamente centrati da
un cambiamento? Mi sembra strano. Mi sembra invece probabile il contrario.
Comunque prendiamo pure in esame questo caso: se l'utente non avesse richiesto
successivamente il log, non sarebbero stati quattro giorni sprecati? E quanti di questi
giorni hai effettivamente perso per anticipare cose che l'utente non ti chiedera' mai,
quanto hai pagato oggi per qualcosa che domani nessuno ti chiedera'?
Si puo' fare di meglio per tenere basso il costo del cambiamento, e senza spendere quanto
stai spendendo tu anticipando.
>>[snip]
>...una delle cose che apprezzo maggiormente di XP e' il
>ciclo di integrazione stretto. Pero' tieni presente che le iterazioni
>del I/I sono *macro* iterazioni: in genere su vari mesi. Il mio approccio
>e' sempre stato di eseguire microiterazioni molto ravvicinate; ho
>visto altra gente usare una sorta di waterfall per le microiterazioni,
>col risultato che possono passare settimane con il processo che
>va per i cavoli suoi senza controllo.
>
I/I == Iterativo incrementale. Cristiano, di nuovo sigle per aumentare la complessita'?
Comunque, ogni quanto metti in produzione? Il nostro progetto dopo 4 settimane era in
produzione, ogni 2 settimane consegnavamo una iterazione e ogni quatto mettevamo
ufficialmente tutto in produzione. Parlando poi di "microiterazioni", noi integravamo le
modifiche ogni 2/3 ore, consegnando una funzionalita, anche piccola, ma funzionante,
completa di test, che come sai noi scriviamo prima e durante la stesura del codice.
("Test first", "Test incrementale" - leggi l'articolo dello zio Bob per vedere
un'esperienza di test-first XP: http://www.objectmentor.com/publications/xpepisode.htm )
Durante quelle 2/3 ore lanciamo _decine_ di volte i test, e in questo modo applichi il
microciclo (test-codice-refactoring) altrettante volte.
>E il trucco nell'usare UML e' tutto nel documentare cose che *non*
>sono evidenti. Per quelle evidenti, un disegno e' una perdita di tempo.
>
Il trucco e' che non devono esserci cose non evidenti, il codice deve essere chiaro e
speaking per tutti. Questo pero' lo puoi fare solo se il codice e' condiviso da tutti,
lavorando in coppia, scambiandosi frequentemente, integrando le modifiche frequentemente.
A quel punto con UML ci puoi fare anche un bel lancio da 3: quello che conta e' il codice.
>E' qui che ti sbagli. :-)
(mi sa di no :-D)
>>Perche' se lo stringessero a sufficienza. tutti quei bei documenti che il
>>processo *deve* produrre, non servirebbero a niente.
>
>Come avevo accennato, UML (o qualunque linguaggio grafico) e' un
>linguaggio vivo, e va usato come tale.
>Non (solo) per documentare *a posteriori*, ma per *comunicare* il sistema
>mentre e' in via di sviluppo - come ho vagamente descritto in un
>post precedente. Per esempio, io uso diagrammi che non sono UML e li
>trovo utilissimi - reti di Petri, (T/E semplificate) - e non
>trovo gli activity diagram altrettanto efficaci.
>
>Per dire, un sequence diagram e' per me - e per il mio gruppo -
>infinitamente piu' chiaro (per *discutere* il problema e la soluzione)
>dell'equivalente in codice. Ci permette di concentrarci sugli aspetti
>essenziali, e verificare idee e design *velocemente*.
>
>Io sono, ahime', ossessionato dall'efficienza (essendo fondamentalmente pigro).
>La documentazione in fase post- e', in questo modo, gratis.
>
Io sono ancora piu' pigro di te, Cristiano. Perche' devo scrivere dei documenti se e'
possibile rendere il codice chiaro e leggibile da tutto il team, in modo che descriva
perfettamente cosa il sistema realizza e come?
Certo, posso usare UML per comunicare, ma mentre sviluppo, magari quando ho un piccolo
dubbio da farmi chiarire da qualcuno (o viceversa) mentre mi sto apprestando a scrivere un
test, ma in generale non lo uso.
Se devo usare UML per spiegare a te il funzionamento di un pezzo di codice, significa che
c'e' complessita, e quindi il codice deve essere rifattorizzato, tutto qui. Altrimenti,
se il codice e' chiaro, speaking, e comunica il suo funzionamento, UML diventa veramente
uno strumento di emergenza.
>> E i nostri amici non venderebbero fior di tool e case, compresi quelli di
>>rountrip diagramma - codice che tu sembri apprezzare.
>
>Per esempio, io non apprezzo piu' Rational Rose. Lo apprezzavo prima,
>perche era sostanzialmente l'unico, e vedevo le potenzialita'. Ma ora
>e' (almeno, l'ultima versione che ho provato) di gran lunga superato.
>Togheter (grazie Ugo :-) e StructureBuilder sono promettenti.
>
TogheterJ == lancio da 3 :-)
Fra l'altro un paio d'anni fa l'ho pure acquistato: ho provato a rimandarlo indietro, ma
niente, non l'hanno voluto! Vorra' dire qualcosa?
>>>Ma una cosa che credo d'aver imparato finora e' che (come dicono gli
>>>inglesi) 1) non ci sono silver bullets; 2) le persone contano in genere
>>>piu' dei metodi. >
>>>
>>Certo, d'accordo sia su 1) che su 2). Io semplicemente sostengo che 1)
>>XP e' attualmente il metodo migliore che ci sia in circolazione
>>(*attualmente*) e che 2) XP funziona proprio' perche' si basa sulle
>>persone.
>
>1) Io sono piu' prudente, in forza di 2). :-)
>2) In che senso gli altri metodi *non* si baserebbero sulle persone?
>
La maggior parte dei metodi (RUP in testa) e' document-centric. Venendo alle persone, se
usi un processo classico e tu hai a disposizione persone skillate e capaci, puoi anche
rimpiazzare un 70-80% del team dall'alba alla mattina. Uno dei punti deboli di XP, e che
viene sempre evidenziato dai detrattori, e' che in un team XP non puoi sostituire le
persone in questo modo. Si creano infatti prima di tutto delle dinamiche di gruppo,
difficili da ricostruire in poco tempo, e inoltre la conoscenza del progetto e' condivisa
e distribuita su tutto il team. E' difficile in un team XP, almeno nella mia esperienza,
sostituire piu' del 40-50% dei componenti senza che il progetto ne venga fortemente
intaccato.
Questo e' comunque non solo una debolezza, ma e' anche una forza. Con un team XP si
raggiunge un grado di, non so come dire, unita', coesione fra le persone, che e'
impossibile raggiungere altrimenti. Nessuno impone, nessuno decide per gli altri, nessuno
batte la testa, tutti collaborano, sinceramente, spontaneamente, per raggiungere
l'obbiettivo. E' una figata, da provare!
Ci sono anche altri aspetti positivi. Essendoci condivisione su tutto il progetto da parte
di tutto il team ("Collective Ownership) il numero di "bus-people" (negli USA e' chiamato
cosi il numero di persone del team che puo' finire sotto un autobus senza che il progetto
ne risenta :-D) e' molto alto rispetto ai processi classici, dove tipicamente un 20-30%
del team e' formato da "insostituibili", quindi esperti designer o di dominio o che hanno
sviluppato una particolare libreria: se perdi quelli, sei messo molto molto male.
>Se uno si limita a riempire boilerplates, fallisce qualunque metodo
>stia applicando.
>
Sorry, "boilerplates" non lo capisco.
>>Uhm.. apoditticamente? disarcivescontantinopolizzantemente? Vedi, anche
>>dalle tue parole traspare una complessita' non necessaria: dal fatto che
>>usi sigle, parole d'uso non troppo comune... :-)
>
>Ridendo.. "apodittico" non e' d'uso comune - in una _discussione_ ?
>
No, di solito non uso termini come "apodittico", "afferire", o sigle se voglio farmi
capire. Cerco la semplicita'. Parlando di me, ricordo che quando inserivo complessita'
(sigle, termini "edotti", frasi a triplo senso) lo facevo solo per mettere in difficolta'
l'interlocutore.
>Le sigle, le uso con in testa la persona a cui sto parlando.. e infatti
>tu le sapevi, nevvero? ;-) Eppoi qui si parla di informatica, mica di
>melanzane. Che, se parli di matematica, non dici mai "integrale"? ;-)
>
Perche' inserire volutamente complessita' quando si possono usare termini semplici e piu'
speaking? Il computer e' fatto apposta, e noi siamo veloci ad usare la tastiera: scrivere
iterativo/incrementale piuttosto che I/I non mi costa niente di piu', e la frase si legge
meglio. Non credi?
>Se uno le sigle non le capisce (io per primo), domanda, o RTFM, che
>fa sempre bene. :-)
>
Ovviamente, si domanda (o lo si spiega) ma perche' non evitarlo quando si puo'?
>(ah, le parole sono le piu' semplici possibile.. come dicevo, non
>necessariamente questo implica siano *semplici* :-)
>
Si. non e' sufficiente usare parole semplici, quello e' solo il primo passo: bisogna
imparare a comunicare con semplicita' e contemporaneamente precisione: si puo' fare.
>>Interessante. Spiegami, comn parole semplici pero', in quale caso la
>>complessita' e l'anticipazione sono utili. Svisceriamo l'argomento e
>>vediamo se riesco a farti passare dalla mia parte :-)
> 1) *leggero* aumento di complessita'.
>
In questo modo tu stai cercando di abbassare il costo del cambiamento. Questo e' proprio
uno degli obbiettivi dell'attivita' di design classica: si tenta di tenere basso il costo
del cambiamento anticipando i punti in cui si pensa esso avverra' ed inserendo in essi
delle artificiosita' (ad esempio la factory che hai usato sul tuo manager nel database
XML) che consentono poi di gestire il cambiamento "spendendo" poco.
Anticipare pero' non e' necessario, e' infatti sufficiente tenere _sempre_ bassa la
complessita. durante _tutto_ il periodo di tempo in cui sviluppi il progetto. Ovviamente
non e' facile, richiede grande sforzo e disciplina ferrea, e soprattutto un metodo: XP.
La differenza e' che tu cerchi di prevedere cosa cambiera' e ti tieni aperto in quei
punti, mentre con XP il software e' globalmente aperto al cambiamento.
> 2) Ragionevolezza dei benefici/fuoco sugli obiettivi
>
> Evitare il complesso di superman: se si parte con l'idea di fare
> una moka, non si deve finire a fare un boiler perche "c'e' caso
> che..". *Anche* se sarebbe possibile fare un boiler, io faccio e
> faccio fare una moka.
>
> Il punto e' che ad un programmatore/designer entusiasta *piace*
> programmare e disegnare software. C'e' (Pirsig insegna :-)
> un'eleganza e un piacere estetico nel mettere insieme codice che
> fa quel che deve fare, e poi di piu', e poi di piu', eccetera.
>
> Se 'sta cosa non si disciplina, il risultato e' overdesign.
>
Il tuo ragionamento e' corretto. Il punto e' che qualunque cosa tu faccia e che non
fornisca valore direttamente al cliente e che non sia da lui richiesta, sono soldi (suoi)
che tu spendi per non dargli nulla. Qualunque cosa tu produca deve essere stata ricbiesta
dal cliente, e quindi fornire a lui valore: se tu decidi di costruire un framework per
gestire un possibile/probabile cambiamento che poi lui non chiede, allora hai violato
questa regola.
> Per fare una stima corretta e' necessario *uscire* dal punto di
> vista "puro software" e tenere presente l'intero scenario - compreso
> il punto di vista del CEO a cui non frega un accidente del software
> di per se', ma deve fare i suoi numeri ogni trimestre... e che
> ha _perfettamente ragione_ a pensarla in questo modo.
>
L'unico punto di vista corretto e' quello del cliente: e' lui che ti paga ed e' a lui che
consegni valore con il tuo software.
> 3) costo *basso* in rapporto ai benefici stimati
>
> Il costo dell'anticipazione, in termini di giorni/uomo, dev'essere
> ragionevole, in rapporto a
>
> - probabilita' d'uso futuro effettivo (stimata)
> - impatto sulla semplicita' d'uso _presente_ :)
> - impatto sulle performance
>
> Lo schedule del progetto aiuta a dare un'idea di "ragionevole": se
> il progetto e' di due anni, una settimana o due sono ragionevoli.
> Se e' di due mesi, due giorni sono ragionevoli.
>
Rimando al commento sul punto 1
> Nota che il costo (di sviluppo) e' in generale dipendente dallo
> sviluppatore. Un'anticipazione ragionevole se la scrivi tu puo'
> non essere ragionevole se la scrivo io, se io sono piu' lento.
> O se la deve mantenere un terzo.
>
Qui tu hai un focus errato: il focus non va sul singolo sviluppatore, ma sul team. Il
costo (di sviluppo) e' in generale dipendente dal team, non dal singolo sviluppatore.
Questo e' un problema derivante al processo che usi tu attualmente, che dipende troppo
dagli sforzi e dalle competenze dei singoli e non e' centrato sulle possibilita' globali
del team. XP si concentra sul team.
>>>Come ho gia' detto, XP (o meglio, quella regola) e' un'ottima cura
>>>per chi fa overdesign...
>>
>>No, mi spiace. XP non e' una cura, e' un metodo da applicare, con
>>rigorosa disciplina...
>
>Ma lo e'. :) Un sacco di gente ha (finalmente) cominciato a leggere
>sugli oggetti, su UML, su s/e, sui metodi etc, si e' entusiasmata, e via
>a over-disegnare. E' - imho - un passo comune a chiunque sia veramente
>*appassionato*. O almeno a molti.
>
>Ed ecco che arriva XP e dice "'mbecilli! Tutte 'ste cose non servono
>ad una mazza, concentratevi sul fare quello che dovete fare!"
>
No, ti sbagli. Ripeto cio' che ho gia' detto. Documentati su XP. Sei stai veramente
dicendo questo sei caduto nell'errore classico di colui che non approfondisce (sto
parlando di XP). XP e' un metodo, rigoroso, disciplinato, il cui scopo ultimo non e'
certamente la cura dell'overdesign. Questo e' un problema che viene affrontato e risolto
da XP ma e' uno dei tanti.
>Una cura, appunto. :-) L'OO e' (come tutto il software) un gran bel
>gioco.
>
C'e' sicuramente, ed e' fondamentale, l'aspetto ludico nel software. Ma, anche qui, e'
solo un aspetto. Sviluppare software significa prima di tutto consegnare valore al
cliente, che ti paga per questo.
>Anche guidare una Ferrari non e' come la Panda. Ci puoi andare piu'
>veloce, ma se non sai che stai facendo e' piu' facile schiantarti.
>
Strano che pero' con XP siano riusciti a fare funzionare il sistema di paghe e contributi
della Chrysler, mentre i due progetti precedenti (realizzati con metodi classici) erano
falliti. Siamo sicuri che abbiamo bisogno della "Ferrari", come la chiami tu? Non sei
magari un po' sovradimensionato per la strada che devi percorrere?
>(PS: la metafora e' stiracchiata: XP non e' una Panda. Ma c'intendiamo. >:-)
No, non c'intendiamo, comunque rispetto la tua opinione. Io soprattutto non vedo la
Ferrari. O se la vedo, tanto per seguire la metafora, non ha i freni :-D
>(scusa la pedanteria :)
Figurati, l'ho appena tagliata :-)
>>Ti assicuro che e' possibile, anche se non e' facile. Leggi anche sotto
>>altre considerazioni.
>
>Avere *tutti* on board *durante* lo sviluppo? Ecchecciai, un quartier
>generale grosso come la lombardia? :-)
>
Ho perso il filo di questo. Cosa vuoi dire?
>>Se domandi a qualunque dipendente Atos, Sesam, GSA se volessero avere il cliente
>>a fianco, ti chiederebbero se sei matto
>
>Probabile. :-) Forse perche' quelle software factory sono fatte da
>persone diverse da uno studente del prim'anno di informatica (il quale,
>in genere, e' almeno cosciente di _non_ saperle, tante cose :-)
>
No, ti chiedono se sei matto per i motivi che ti avevo esposto:
=] Loro *non* vogliono avere il cliente a fianco, perche' il cliente
=] potrebbe cambiare idea, potrebbe farti fare d'autorita' delle cose
=] che non erano previste, puo' farti fare piccoli ed infidi cambiamenti
=] sui requisiti che ti fanno incasinare e perdere settimane di tempo.
>>In XP invece e' esattamente il contrario: se il cliente cambia idea, noi
>>siamo contenti. E non perdiamo tempo. Embrace change!
>
>Ecco, io non sono X fino a quel punto. Come dicevo, sono interessato
>anche ad altre cose, oltre al software. :-)
>
Anche a me. Ti ricordo che una delle pratiche di XP e' 40 hours/week.
Cosa intendi dire con questa frase?
>Io sono contento se un cliente _non_ mi cambia le specifiche. Quello che
>so e' che quasi sempre un cliente le vuole cambiare, e uso le tecniche
>note per far contento lui e rimanere contento io anche in quel caso. :-)
>
>Occhio che - per contratto - io voglio (quando e' possibile) avere
>la possibilita' di dire di no.
>
>Altrimenti parti con un progetto per una bicicletta e il cliente ti puo'
>chiedere un razzo.
>
E che problema c'e'? Evidentemente non sapeva quello che voleva (sai la novita'!) e voleva
il razzo. Non capisco: se durante lo sviluppo lui scopre di volere un razzo inizio a
lavorare insieme a lui per realizzare il razzo. A che gli servirebbe a quel punto la
bicicletta? Perche' non dovrei farlo, scusa? Lui mi paga, lui decide. Spiegami.
>...e lui *non* si aspetta un razzo, e sa perche'.
>
Non so, se ti chiede un razzo a me da' l'idea che lui voglia un razzo. Sicuramente
dobbiamo cercare di chiarirci le idee insieme, e magari invece del razzo viene fuori che
lui voleva un'automobile invece che la bicicletta. Io gliela faccio, non c'e' problema.
>Il trucco e' mantenere continua sintonia col cliente
>in modo che sia tu che lui sappiate che bicletta state facendo...
>
In effetti e' molto facile stare in sintonia con il cliente se usi XP: gli consegni una
release in produzione ogni 4 settimane ("Small releases"), ce l'hai seduto di fianco a te
("On site customer"), lui decide ogni 2 settimane che feature sviluppare o se cambiare
direzione ("Planning game", release planning & iteration planning)
>Se ho bisogno di fisica nucleare, *devo* chiedere ad un fisico nucleare,
>e una volta che ce l'ho in team le parti di fisica nucleare saranno
>piu' facili per lui che per me. XP o non XP.
>
Non mi sembra stessimo parlando di competenze di dominio ma comunque rispondo volentieri:
non c'e' problema, chiedo al cliente, e se non lo sa gli spiego il problema e
probabilmente contatteremo un fisico nucleare.
Provo a riprendere il filo del discorso:
>>>Cose non complicate per me, per esempio, sono intricatissime per il mio
>>>programmatore piu' junior.
>>
>>Beh, nel tuo caso c'e' un problema nel team: se tu applicassi XP questi
>>problemi non li incontreresti. Se vuoi approfondiamo.
>
>Approfondiamo. :) Non vedo come sia un problema di team
>
E' un problema di team perche' evidentemente il tuo team non e' equilibrato: concordo che
c'e' sempre una persona un po' piu' esperta (che di solito assume il ruolo di coach, una
forma sottile di capo progetto, se vuoi approfondiamo) ma in generale il team e' formato
da persone che hanno competenze omogenee e che, se non ce l'hanno, le acquistano dopo un
periodo di solito non troppo lungo semplicemente lavorando nel team. In XP ad una stazione
di sviluppo lavorano sempre due persone ("Pair programming"), sviluppano tutto il software
insieme e si scambiano di frequente sia fra di loro che all'interno del team: ti assicuro
che il newbie, dopo poco tempo, inizia a "rendere" come un componente standard del team.
Aiuta molto ovviamente anche l'uso di un design semplice ("Simple Design"), si deve usare
sempre il design piu' semplice che porta alla realizzazione della funzionalita' perche' i
requisiti cambieranno domani, quindi si realizza solo quello che e' necessario per
soddisfare quelli odierni. Anche l'uso di uno standard di codifica condiviso ("Coding
Standard) aiuta ovviamente, soprattutto se questo richiede che il codice sia speaking.
>...mostrare come certi problemi non siano risolti e certe
>tecniche siano applicabilissime (e migliorino il risultato) anche in
>ambito XP.
>
Ottimo. Approfondisci pure l'argomento.
>>>>Potrei dire cbe una soluzione e' semplice se non anticipa nulla o se
>>>>chiunque nel tuo team semplicemente leggendo il codice ne comprende
>>>>perfettamente il funzionamento.
>
>Ma allora fattorizzi tutto al minimo comune denominatore, il
>programmatore junior. Che e' sempre li'. :-)
>
Ovviamente no.
>Il trucco e' proprio il contrario: esporlo a cose piu' complicate, aiutandolo
>a diventare non-junior (il problema e' che poi se ne va.... o spesso non se ne va :).
>
E' ovvio, come gia' ti spiegavo sopra, che il principiante deve crescere. XP ti aiuta
anche in questo, ti porta necessariamente a farlo crescere. E, certo, puo' succedere che
abbandoni. come puo' succedere che il progetto fallisca.
Tornando al punto, nel tuo caso, come dicevo sopra, hai un problema di team: il tuo team
non e' equilibrato. Le pratiche XP portano automaticamente il team ad autoequilibrarsi, e'
molto semplice. Ma l'ho gia' spiegato sopra :-)
>>Si, ma chi legge fa parte di un team. Non si parla di persone
>>"sconnesse" fra di loro (l'analista, il designer, il sw-architect, il
>>programmatore genialoide, il programmatore sgualfo, ecc.ecc) ma di un
>>team.
>
>Non so in che mondo vivi tu :) ma i team sono fatti da individui, ognuno
>con sue caratteristiche e preferenze, e che restano individui. E magari
>dove lavori tu e' facile trovare gente: ma qui no, tantomeno gente in
>gamba.
>
>Essi non sono "sconnessi": ma non perche' parte di un collettivo Borg, ma
>perche' comunicano - e hanno gli strumenti per comunicare *anche* quando
>le loro competenze sono profondamente diverse - che e' il caso comune.
>
No, qua non e' facile trovare gente. ma con XP e' facile inserirle nel team. E XP ti
costringe ad imparare a comunicare con tutti i componenti del team.
>UML e' uno di tali strumenti - che e' il motivo per cui lo uso.
>
E' uno strumento aggiuntivo, che si puo' usare ad esempio quando ci fosse un problema di
comunicazione nel codice. Altrimenti il codice ti comunica il proprio funzionamento. Se il
codice e' speaking ("Coding Standards"), e' stato sviluppato da tutti ("Collective
Ownership"), e' fornito di test che ne mostrano il funzionamento ("Continuous Testing",
"Unit, Functional, Acceptance Test), e' nella forma piu' semplice possibile
("Refactoring"), e' conosciuto da tutti nella sua interezza a causa del fatto che si
integra ogni 2/3 ore ("Continuous Integration"), ed e' supportato da una metafora
organizzativa chiara e condivisa ("System Metaphor") allora non c'e' problema. Pero' forse
ho condenzato un po' troppo: approfondiamo i singoli argomenti?
>*Se* per "sconnessi" intendi l'archietto che fa le specifiche e le passa
>al designer che fa il disegno che passa al programmatore che implementa
>che passa al tester che testa, il tutto senza comunicazione all'indietro
>e feedback, questo e' waterfall - e non quello di cui sto parlando io.
>:-)
>
No, intendo non omogeneei. Team in cui ci sono delle persone con competenze od esperienza
troppo distanti, in cui esiste il sw-architect (che anche se non lo e' di nome lo e' di
fatto), l'esperto del dominio, il programmatore genialoide, il programmatore sgualfo.
Questo non implica assolutamente waterfall, ma semplicemente indica che le decisioni di
volta in volta non sono prese dal team ma sono prese da singole persone piu' esperte: non
si tratta di decisioni collettive ma di decisioni di singoli. Non lavora il team, ma
lavorano i singoli. In XP le pratiche sono orientate al team e, come ho gia' detto, alcune
sono proprio dirette ad aumentare e a rinforzare le dinamiche di gruppo ("Pair
Programming", "Planning Game", "Collective Ownership"...). Disponibile per approfondire.
>>Interessante il fatto che tu dica "Beck e' il primo a dirlo". Sicuro?
>
>Ricordo una discussione su comp.object (o comp.s.e.) in cui Martin o Beck
>dicevano pressappoco...
>
Io no. Lasciamo perdere comunque, al limite la prossima volta che lo vedo glielo chiedo,
e' anche possibile che abbia cambiato idea.
>>>Il problema e' - ovviamente - nell'"esprime tutte le idee etc". :-)
>>Tutti quegli aspetti sono problematici da definire, se ci pensi, e c'e'
>>un unica persona che ti puo' aiutare a chiarirli, e, paradossalmente, e'
>>il cliente. E' lui che ti guida nello sviluppo del tuo software, non sei
>>*mai* tu che guidi lui.
>
>Temo di non essere d'accordo: col cliente, e' piu' un loop in feedback...
>
>...io posso proporre al cliente cambiamenti, innovazioni e miglioramenti
> che *lui* non si sognerebbe...
>...informazioni, guide e stimoli viaggiano in due direzioni...
>...costante valutazione e feedback da *entrambe* le parti...
>
>Poi sta a lui (il cliente) decidere: ma un conto e' la decisone, un
>conto la guida. Io sono guidato spessissimo da altri ragazzi nel mio
>team, anche se prendo le decisioni e il _mio_ sedere e' quello che riceve
>i calci se qualcosa non va bene.
>
Infatti. C'e' ovviamente del feedback da entrambe le parti, e uno dei tuoi compiti
istituzionali e' proprio quello di suggerire business, e di dare tutte le informazioni al
cliente, anche quelle che non ti convengono, ma e' il cliente che decide cosa vuole. Tu
puoi suggerire, ma non imporre. Il cliente decide. Comunque, se vuoi, rifattorizziamo la
mia frase cosi, tanto per non avere dubbi sul significato:
"E' il cliente che decide lo sviluppo del software, non sei *mai* tu che decidi per lui."
Ok?
>Ancora: la lezione di XP - che io apprezzo per la *chiarezza* e l'enfasi
>con cui cose gia' note sono espresse - e' che non si puo' chiudere il
>cliente fuori, e l'analisi fatta inhouse e' pseudo-analisi (non mi
>ricordo chi l'ha detto, ma e' tendenzialmente vero). Ma ancora, questo
>e' del tutto indipendente da XP, se uno 'sta cosa la fa con qualunque
>altro metodo (esistono progetti *di successo* eseguiti in waterfall.. :-)
>
Questo e', di nuovo, solo uno dei problemi che vengono affrontati e risolti da XP ma e'
uno dei tanti.
>>Allora, lo scriviamo 'sto libro?
>
>In effetti, ti volevo riproporre la cosa. :-)
>
Son qui, la mia mail la conosci :-D