Newsgroup: it.lavoro.informatica
Titolo: UML (per una volta parliamo di tecnica...)

Ciao a tutti!
Giusto per saltare da un luogo comunque all'altro. Qualcuno di voi ha
utilizzato in maniera 'produttiva' UML nell'ambito di progetti concreti e
lo ha considerato utile? Sinceramente non lo conosco ma stavo pensando di
leggere qualcosa in merito. In particolare vorrei sapere.
1) Se qualcuno lo ha utilizzato e lo considera quindi utile, oppure se è
solo un formalismo da fresco laureato in ingegneria senza alcuna
conoscenza 'pratica'
2) Se può essere considerata una buona carta da giocare in fase di
colloquio la conoscenza di UML ed avere esperienza di esso.
3) Eventualmente un consiglio su un buon testo. Ovvero qualcosa che riesca
a far convergere teoria e 'vile' pratica.
Un saluto a tutti!
-- 
-----
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 a far convergere teoria e 'vile' pratica.
Sto leggendo proprio in questi giorni "UML distilled", di Martin Fowler. E'
stato tradotto in italiano e mi pare sia un testo molto pratico.
Ciao,
-- 
Marco

 conoscenza 'pratica'
Quoto... :)
-- 
______________________________________
Luc (31, CO, VC++ Programmer)
Editorial Systems Software development
______________________________________

 a far convergere teoria e 'vile' pratica.
Ti sconsiglio il famoso "UML distilled": troppo superficiale. Meglio un
testo orientato all'intero ciclo di vita.

Va saputo usare. In genere e' una scusa da parte dei grossi committenti per
infilare loro risorse (che ormai sanno fare solo quello) nei progetti che
danno in subappalto.
Come tutti i tool deve essere perlappunto un tool, non una camicia di forza.
Il rpoblema e' che il committente non sa leggere neanche gli use case
diagram, per cui ti tocca fare il modelling UML, POI scriverci sopra un
documento word, e tenere aggiornato il tutto.
Se il progettista non ha le idee chiare fin da subito, hai il 50% di
overhead. Sperimentato.
-- 
---
Francesco Galli / Cinghiale Mannaro
Personal: 
http://cinghialemannaro.splinder.com
TMS project: 
http://tms.inera.it

 leggere qualcosa in merito. In particolare vorrei sapere.
 
per i progetti grandi 'dovrebbe' essere necessario...
spesso pero' chi commissiona il progetto vuole subito vederlo
funzinare (almeno in parte) e quindi spesso le specifiche prese dal
cliente,non vengono sempre tradotte in diagrammi UML...
e poi cio' dipende anche dalo linguaggio che si usa...
per chi programma a oggetti (java c# ) e' certo piu' utile
rispetto a chi usa i 'procedurali'
un'altra cosa importante e' poi: quale tool UML usare? rational rose
Visio argouml? in modo da mettere subito in pratica cio' che si impara
nella teoria.


Concordo. tra quello che ti scrive Fowler e mettere in pratica c'e' il
classico mare o oceano d mezzo
/CM

 nella teoria.
   Rational Rose costa $cifrone. Argo o Poseidon vanno benissimo.
FG

Francesco Galli ha scritto:


quali sono le diff maggiori?  RR mi sembra consenta il reverse engineriing
che gli altri 2 free non consentano...o mi sbaglio?


 conoscenza 'pratica'
Innanzitutto non lo insegnano solo ad ingegneria (so che non volevi dire
questo ma di questi tempi il flame e' aperto). :-)
E' oramai uno standard de facto sia nel mondo j2ee che in quello .net.
Ovvio che non sia la soluzione perfetta per tutti i problemi ma al momento
e' il metodo di analisi piu' seguito. Ognuno potrebbe inventarsi un nuovo
modello di analisi perfetto per il proprio contesto, il problema e' poi
dover tradurre la tua analisi agli sviluppatori e a tutti coloro coinvolti
nel processo. Direi che oggi sia un must in qualsiasi azienda che abbia un
minimo interesse a standardizzare i propri processi.
Ciao


 che gli altri 2 free non consentano...o mi sbaglio?
   Non mi ricordo di preciso perche' e' una cosa che ho fatto qualche


 che gli altri 2 free non consentano...o mi sbaglio?
RR ha un ottimo tool per generare la documentazione.
gli altri credo di no.
Cě impieghi un attimo... ^_^

Vero :-) pero' sono contrario al software pirata per principio, e dubito che
il nostro Indomito spenda $cifrone_stellare per studiarsi UML con RR, no? :)


 il nostro Indomito spenda $cifrone_stellare per studiarsi UML con RR, no? :)
Chi puo' dirlo? se l'indomito fosse un indomito cinese... non lo escluderei
;-)


 
Dai un'occhiata ad Enterprise Architect, non costa troppo, e supporta 
già UML 2.0.
-- 
Free Download --> "AB...C#, Guida alla programmazione"
Il manuale in italiano per imparare c#, scaricalo da 
www.dotnetarchitects.it
email: 
nagbavb....@qbgargnepuvgrpgf.vg
 (ROT13-encrypted)

Quoto... :)
eh gia', e' arrivato il genio...che evidentemente non saprebbe nemmeno
usarlo e manco sa dell'esistenza, che so, di toolettini da migliaia di euro
come Rational Rose e affini...ROTFL


[cut]
UML è un linguaggio ma soprattuto uno strumento di lavoro e come tale deve
essere usato e adeguato alla vita reale di tutti i giorni.
Io lo uso molto spesso, praticamente per tutti i miei progetti, ti consente
una visione di insieme delle classi e delle relazioni tra di esse nel tuo
sistema.
Però ribadisco: uno strumento deve essere al servizio dell'uomo e non il
contrario.
Che la forza sia con te
Claudio
P.S. Io uso Enterprise Architect (della sparxsystems), disponibile anche in
versione trial per 30 giorni.

lo sto studiando proprio in questo momento...bella materia, se non fosse 
per la parte teorica di ingegnerizzazione dei processi di produzione 
software (analisi,design,coding,testing,manutenzione), cmq credo che 
l'UML serva principalmente all'interno di grosse realtà aziendali, dove 
la comunicazione tra i vari partecipanti al progetto è indispensabile e 
non nelle piccole aziende dove il contatto è più diretto, pertanto non 
credo che sia indispensabile, ma che sia utile e che sia un qualcosa in 
più nel proprio bagaglio di conoscenza.
Saluti da uno studente.^^

 sistema.
Si, ma se il codice è fatto bene, e quando dico bene voglio dire bene, tools 
come UML hanno meno utilità. E' il codice che parla già di per se. Specie se è 
codice "tuo" (del tuo develop-team), nel senso che ci lavori da molto tempo... 


 codice "tuo" (del tuo develop-team), nel senso che ci lavori da molto
tempo.... 
grazie al beeeeeeep
:-)
la documentazione (tra cui anche UML) serve proprio, tra l'altro, a far
capire le cose a chi eventualmente si ritrovera' a lavorare
dopo di te al tuo progetto


 come UML hanno meno utilità. E' il codice che parla già di per se. Specie
se è > codice "tuo" (del tuo develop-team), nel senso che ci lavori da molto
tempo...
Se il codice è scritto bene bene (come dici tu) deve poter essere
"tramandato" anche a chi viene dopo di te e quindi ben documentato. Un class
diagram parla più di mille commenti.

 Un saluto a tutti!
anche a te, buono studio e non fare classi troppo ciccie! :-D
ALFI_
-- 
Cerca finché non trovi, ma se trovi significa che hai sbagliato qualcosa.
                                                         - Proverbio Zen -
ALFI_

 come UML hanno meno utilità. E' il codice che parla già di per se. Specie
se è > codice "tuo" (del tuo develop-team), nel senso che ci lavori da molto
tempo...
Se il codice scritto bene bene, lo capisci solo tu....allora è scritto male
male.
Senti questa:
Un giorno un collega (ingegnere) si avvicina e mi fa "Ho dato le dimissioni,
devo passarti il mio progetto".
"Ok, dove trovo il documento del progetto ?"
"Quale documento ?"
"Non hai un pezzo di carta che mi aiuti a capire come è composto il sistema
?"
"No.....è tutta nella mia testa".
Inutile dire che ho versato sangue e lanciato imprecazioni verso l'ex
collega per tutta la durata del progetto.
Non aggiungo altro.

 codice "tuo" (del tuo develop-team), nel senso che ci lavori da molto tempo... 
Eh sì, difatti individualmente o per progetti piccoli è suff un class 
diagram da tenere aggiornato, non un progetto UML completo che è 
descrittivo al massimo e serve solo in una realtà dove le fasi di 
analisi, progettazione, implementazione e testing avvengono con ciclo 
iterativo continuo, con parecchie figure professionali coinvolte e con 
una buona separazione dei compiti.
Se devi far implementare un progetto molto grosso (milioni di LOC) a 
parecchie decine di programmatori è indispensabile.
Il costo maggiore del sw e anche il tempo maggiormente spesoci sopra sta 
nella manutenzione per sw grossi, senza una standardizzazione del 
processo di sviluppo e uno strumento valido come UML regna il caos e i 
tempi di lavoro, e anche la qualità, ne risentono molto.


 "tramandato" anche a chi viene dopo di te e quindi ben documentato.
Il che vuol dire che non devono essere commentate tutte le linee di codice, ma 
solo quelle critiche. Generalmente un team di sviluppo non viene sostituito al 
100% ma spesso in poche unità. I "sopravvissuti" sapranno spiegare, quando ce 
ne bisogno, come funziona il codice.
Non mi venite a dire che un nuovo programmatore, se si utilizza ULM, è in grado 
di partire in tromba con lo sviluppo...


 male.
Pensa a quando uno non capisce il proprio di codice, cioè quando lo riprende 
dopo alcuni anni... Con l'esperienza si impara a far le cose capibili per i 
posteri (te stesso compreso).
Ma di programmatori buoni cosi siamo in pochi... ;) 


 Ma di programmatori buoni cosi siamo in pochi... ;)
Te la canti e te la suoni ? :)

 di partire in tromba con lo sviluppo...
Se conosce UML può già partire a studiarsi la documentazione UML 
prodotta e dopo sì che può partire in tromba. Ovviamente deve conoscere 
il linguaggio e le librerie usate.
Serve a questo UML, non perdi tempo a capire come hanno fatto le cose 
altri e se devi migliorare qualcosa hai una visione dettagliata ma più 
grafica di molti aspetti, il che descrive meglio l'architettura e le 
scelte progettuali più dettagliate.


 a oggetti è un buon supporto.
Sì che si è andati avanti ma non sai a che costi! Esiste un preciso tool 
di analisi di grossi progetti sviluppato da un tipo che si occupa di 
ing. del sw a 360°. Sto qua è Prof. a Vienna e fa consulenza a aziende 
come Nokia, Siemens, IBM, Intel, Oracle...
Coi suoi studi ha analizzato la storia dei sw di grosse dimensioni 
(decine di milioni di LOC) e ha confrontato le metodologie dei processi 
di sviluppo passate e quelle recenti, le varie scuole di pensiero e i 
risultati prodotti.
Uno strumento come UML per l'OOP è in grado di semplificare (di fatto 
per rappresentazione e standardizzazione) e rendere gestibile grossi sw 
a tal punto da abbattere i costi di parecchie unità di grandezza, in 
particolare in termini di manutenibilità.
Però non si deve pensare che solo per sw da milioni di LOC sia 
indispensabile. Per la mia esperienza quando un sw supera le 5000 linee 
(gui esclusa) di codice inizia a chiamare a gran voce UML, almeno il 
diagramma delle classi!
Poi se un programma è particolarmente complesso, fatto di svariate 
classi piccole intrecciate in modo stronzo fra loro, o con 
un'architettura molto complessa, anche se ha solo 2000 LOC e lo devi 
sviluppare tu da solo, un diagrammino delle classi e qualche use case 
non porta via troppo tempo e fa girare meno la testa quando si ragiona 
sul progetto.


 sul progetto.
Mi trovi perfettamente d'accordo. Io da quando l'ho scoperto, non ne faccio
più a meno, anche se devo dire che delle 4+1 viste utilizzo solo gli
use-case e i class-diagram. Le altre viste, anche se molto utili
affascinanti non ho mai avuto modo di usarle nella vita di tutti giorni,
vedi tempi di scadenza brevi, capo rompipalle, etc. etc.


 vedi tempi di scadenza brevi, capo rompipalle, etc. etc.
Sì il class diagram è l'unico davvero fondamentale anche per progettini.
Io fortunatamente ho avuto modo di usarli tutti quanti, in modo 
approfondito e con una bella documentazione di 200 pagine per un 
progetto, forse il più grosso che ho fatto all'università (progetto in 
UML e sviluppo in J2EE per gestione esami tesi e altre cose, da 
integrarsi ad un più grosso progetto in comune con gli altri gruppi del 
corso).
Nella vita reale spero bene anche io di non trovarmi a dover fare troppi 
diagrammi e anche il codice, però se devo solo disegnare gli omarini e 
analizzare bene le specifiche mi diverte abbastanza :-)


 testo orientato all'intero ciclo di vita.
Il libro fornisce un'introduzione allo Unified Modeling Language senza
addentrarsi nei dettagli di questo strumento grafico, ormai uno standard di
fatto per la progettazione di software "object-oriented". Più che un fine
in sé, la presentazione di UML è uno strumento per giungere a illustrare i
fondamenti della progettazione a oggetti, concentrandosi sugli aspetti
concettuali e sui principi di base, essenziali per realizzare software
orientato agli oggetti di buona qualità.(leggi la recensione completa) 
http://www.webriviste.com/libri/libro19.asp

 Un saluto a tutti!
Andrea

 Un saluto a tutti!
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 significative) notevole e la cosa avrà il solo risultato di nuocere.
Esatto.
Il problema e' che nel 100% dei casi in cui mi e' capitato di
lavorare con UML queste cose le devi fare anche
se usi UML in quanto o ti chiedono di aggiungere una feature
che il generatore non supporta, o ti chiedono di cambiare modello
per tenere conto di cose di cui prima non si ci si era resi conto o
semplicemente ti accorgi che tu non hai tenuto conto di tutto
quello che dovevi fare, ecc => una volta che hai generato il codice
tornare indietro diventa un inferno.
Ciao,
Marco.


 danno in subappalto.
Noto (con dispiacere per la verita') che non sono l'unico a constatare
che le cose vanno cosi'.
[SNIP]


 Un saluto a tutti!
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 "No.....è tutta nella mia testa".
Eppure io (ingegnere, fortemente avverso all'ingegneria del software in
generale),
quando me ne sono andato e al progetto a cui lavoravo c'e' andato
a lavorare un altro ho scritto circa 50-60 pagine (oltre
ai vari documenti scritti con Rational Rose in fase di progettazione
e puntualmente stravolti in fase di implementazione) 
per descrivere come era fatto il  database prima della
reingegnerizzazione, 
come era stato fatto dopo, cosa significavano le varie tabelle
e i vari campi, quali procedure facevano quella cosa, 
quali facevano quell'altra, perche' magari c'erano due procedure che 
facevano piu' o meno la stessa cosa, ecc. oltre che scrivere abbondanti
commenti al codice, classe per classe, methodo per metodo, funzione per
funzione, scrivendo per ogni funzione o metodo quale e' il significato dei
parametri, il valore di ritorno e qualche nota sulla funzionalita',
nonostante fossero
qualche decina di migliaia di linee di codice (scritte rigorosamente
"a manina", ecc.
Eppure non mi e' mai capitato di vedere nessuno (ingegnere o meno) che
quando se ne va fa altrettanto (in genere anche perche'
devono farlo "per ieri". Io quando l'ho fatto lavoravo per l'universita'
che ha tempi un po' piu' lunghi).
Ciao,
Marco.


 diagram parla più di mille commenti.
A patto che il "class diagram" non sia quello pensato in fase di
analisi e che poi e' stato completamente stravolto in fase di
implementazione.
Altrimenti hai voglia di class diagram...
E se riesci a tenere aggiornata la documentazione UML man mano che
sviluppi e contemporaneamente rispettare i tempi previsti
ti faccio i miei complimenti: in 7 anni non ho mai conosciuto nessuno
che ci riesce.


 scelte progettuali più dettagliate.
Io vorrei capire quanto tempo ci mettete a tenere
aggiornata la documentazione mentre sviluppate.
Io non ci riuscivo nemmeno quando avevo a disposizione
i tempi biblici dell'universita' => facevo molto ma molto prima
a reingegnerizzare il codice per renderlo leggibile anche ad altri.


 Ciao
Ciao Nicola


 tempi di lavoro, e anche la qualità, ne risentono molto.
Da cosa deduci questa tua convinzione ?


 Inviato via 
http://arianna.libero.it/usenet/


 Marco.
ciao Nicola


 a dismisura.
Devo dire che si, effettivamente, all'inizio i tempi si allungano, e penso
che il motivo sia dovuto al fatto che si è obbligati in anticipo a decidere
e pensare quello che si deve fare e come farlo, unita al fatto che si deve
apprendere una modalità operativa diversa.
A questo aggiungo anche, che l'allungarsi del tempo sia dovuto più ad una
sensazione che alla realtà. Mettersi a testa bassa a scrivere codice, ti fa
credere di spendere meno tempo che a pensare prima che cosa scrivere. E,
purtroppo, devo dire che anch'io ho questa abitudine.
Da qualche tempo, sto usando UML, nel momento in cui devo accingermi a fare
una nuova release, e devo dire, che così facendo, ovvero, analizzando e
valutando prima le cose che sono da fare, ho la possibilità di risparmiare
un bel po' di tempo, soprattutto quando metto mano a prodotti realizzati un
anno fa. Ma la cosa "divertente" e che ti accorgi di problemi che nella
prima stesura non hai neanche ipotizzato che si potessero verificare. E tra
questi, una cosa che trovo molto spesso è la ridondanza del codice. Ovvero
classi, derivate male o non derivate, quando il farlo ti avrebbe
risparmiato, anche solo un centinaio di righe di codice. Non sono molte, ma
se pensate che nell'ultimo progetto "grande" ho realizzato un qualcosa come
40 classi, vi potete rendere conto anche voi, che magari una valutazione più
accorta dell'architettura dello stesso, mi avrebbe fatto risparmiare un po'
di tempo, che avrei potuto dedicare a curare meglio altre parti, che, per
motivi di tempo, non ho avuto la possibilità di fare.
Prima o poi, mi devo decidere a fare il gran passo, ed utilizzarlo non solo
nel momento in cui devo fare manutenzione, ma anche in fase di
progettazione.
ciao,
Maurizio.

 a reingegnerizzare il codice per renderlo leggibile anche ad altri.
ah e ci metti poco tu a reingegnerizzare 10000 LOC  di un sw complesso 
per renderlo leggibile agli altri, assumendo che quel sw l'hanno scritto 
diciamo in almeno 5 o 6 persone?
Io mi sono trovato in mezzo a incastri tali che avrei fatto prima a 
rifare da 0 il progetto comprensivo di documentazione UML piuttosto che 
reingegnerizzare quello già esistente!
Dipende sempre dal progetto, UML a mio avviso per certi tipi di progetti 
complessi in architettura e in processo di sviluppo è fondamentale, per 
piccolio semplici (in architettura) progetti meglio fermarsi al class 
diagram.


 a reingegnerizzare il codice per renderlo leggibile anche ad altri.
Beh, adesso, ci sono dei tool che ti permettono di tenere la documentazione
aggiornata, anche in fase di sviluppo, l'unico problema è che devi
commentare in modo corretto il codice -> poi basta che premi un bottone e
tutto si produce in un lampo. In questo momento, lavoro in java ed uso
NetBeans. E ti dico che produrre la documentazione del codice in javadoc è
veramente una cosa mooooooolto semplice. Soprattutto, ti permette di non
separare la fase di documentazione con quella di produzione.
Se poi, a questa, aggiungi anche la parte UML, vedrai che le cose filano via
che è un piacere, ed il tempo speso in più ti ritorna sempre, soprattutto se
poi, su quel cosice, devi fare manutenzione a distanza di tempo.
Ciao,
Maurizio.

 Da cosa deduci questa tua convinzione ?
convinzione? Ma hai studiato ing. del sw all'università? Hai mai 
lavorato ad un progetto di parecchie decine di migliaia di LOC a cui 
lavorano decine di persone di impostazione scientifica diversa 
(matematici, ingegneri, fisici, informatici...) sviluppato oltre che nel 
tuo paese in altri?
Hai mai letto tutti i documenti scientifici prodotti da chi analizza e 
fa consulenza alle più grosse sw house del mondo per valutarne i costi 
dei vari processi di sviluppo? Sai quali sono i principali processi di 
sviluppo e la loro efficienza?
Le deduzioni... non sono deduzioni.
Sono cose che ho studiato, esperienze dei maggiori professionisti del 
mondo lette su libri e riviste scientifiche (ACM, IEEE) esperienze dei 
docenti che fanno consulenza a questi, seminari di professionisti che 
direttamente dalle aziende ci hanno fornito informazioni su questi 
aspetti dei processi di sviluppo.
Tu per quale motivo invece hai dei dubbi su quanto ho quotato?


 che ci riesce.
Fatemi i complimenti! :-)
-- 
Free Download --> "AB...C#, Guida alla programmazione"
Il manuale in italiano per imparare c#, scaricalo da 
www.dotnetarchitects.it
email: 
nagbavb....@qbgargnepuvgrpgf.vg
 (ROT13-encrypted)

 Maurizio.
ciao Nicola


 Fatemi i complimenti! :-)
complimenti :-)))

 progettazione.
questo è esattamente il senso di UML: lo usi fin dalla fase di analisi, 
per poi mantenerlo aggiornato in progettazione e implementazione.
Un ciclo di vita iterativo che riporta dall'implementazione (o meglio 
dal testing) alla progettazione e via a ciclare infinite volte, può 
essere pensato solo per grossissimi progetti, che vanno avanti per anni 
e gestiti da decine se non centinaia di persone.
Per piccoli progetti l'extreme programming a mio avviso da i migliori 
risultati.
Bisogna essere ben consapevoli di quale tecnica utilizzare ed avere 
esperienza di entrambe, se no si rischia di applicare l'XP a progetti 
grossi che vengono sviluppati in fretta ma che poi avranno tempi di 
manutenzione lunghissimi (i costi aumentano spaventosamente e la qualità 
del sw cala) oppure si rischia che per un progetto fatto da 3 persone 
che una volta finito (6 mesi) sarà proprio FINITO, ci sia una valanga di 
documentazione che non serve a nessuno e lo stesso progetto si poteva 
fare in 4 mesi.
ALFI_


 Marco.
Andrea

 Marco.
Andrea

aspetti dei processi di sviluppo.
Ma tu, in UML, ci hai lavorato MAI? Perche' in tutto il thread ripeti la
stessa salsa cambiando poche parole, e non mi sembra che tu uml l'abbia mai
usato davvero. E qui oltretutto lo affermi a gran voce: l'hai solo studiato.
Altrimenti il concetto di "overhead" l'avresti chiaro. E non diresti, come
hai fatto altrove, che un progetto da 5000LOC "chiama a gran voce uml". Al
limite da 5000KLOC, e *forse*.
Tu per quale motivo invece hai dei dubbi su quanto ho quotato?
-- 
---
Francesco Galli / Cinghiale Mannaro
Personal: 
http://cinghialemannaro.splinder.com
TMS project: 
http://tms.inera.it

 in 2
   E ci credo! Hai mai provato a chiedere quanto costa? :-) :-)
   io si. Mi serviva in un grosso progetto in cui
$subappaltatore_incompetente aveva obbligato tutti a usare Rational Rose per
piazzare $numero_impressionante_di_incompetenti_tecnici in ruoli chiave.
Ovviamente volevano Rational Rose anche dai subappaltatori e non volevano
pagare la licenza.
   La soluzione e' stata banale: Poseidon e esportazione in xml :)

 Tu per quale motivo invece hai dei dubbi su quanto ho quotato?
Non mi hai detto i tuoi di dubbi, io non devo risponderti di nulla sei 
tu che hai dei problemi con quanto affermo io.


tu che hai dei problemi con quanto affermo io.
   Questa frase non e' mia, e' tua... sembra mia per un errore di quoting.
Lasciamola da parte, non c'entra nulla.
FG

 Relazione biunivoca valida per entrambi.
sì hai ragione, poi a lavorare con persone che la pensano diversamente 
si finisce per imparare sempre qualcosa, ritiro quello che ho detto :-)


 diagram.
Io mi fermerei agli use case in entrambi i casi, pero' ognuno ha i
suoi gusti :-)
Ciao,
Marco.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 wrote in message
news:d71khf$b3d$
1...@mophus.csi.it

Sui commenti al codice concordo al 100%.
Qualche volta ho provato anche a usare javadoc per produrre
la documentazione del codice C++ che scrivo, cercando di scrivere
i commenti in modo riconoscibile da javadoc. Poi pero' ho pensato:
"ma se io ho il file con il codice e relativi commenti, perche'
non posso leggere quello invece della roba che viene prodotta
da javadoc "? Sinceramente non ho ancora trovato una valida
risposta.
Non mi ricordo se te l'ho gia' chiesto,
ma tu sei quel Maurizio Penna (almeno mi sembra di ricordare
che il nome fosse questo) che si e' laureato a Pisa 
e che ora lavora a Roma,  con il quale ci siamo incontrati
sul lavoro qualche mese fa (a dicembre mi sembra) dicamo in zona 
"Roma Ovest" ?
Ciao,
Marco


 Fatemi i complimenti! :-)
Complimenti!!
Secondo me non sarebbe male sapere in quanti ci riescono.
Per ora mi sembri l'unico (pero' non vale. Io avevo detto di
non aver mai conosciuto nessuno, e a te mica ti conosco :-) ) .
Ciao,
Marco.


 Tu per quale motivo invece hai dei dubbi su quanto ho quotato?
Vedi sopra.
Che esistano delle bellissime teorie non lo metto in dubbio ma sai
come sono state dimensionate (non da me per la verita)
le code di molti server sui quali lavoro ?
Pensi che siano state applicate le spettacolari regole
della teoria delle code ? Pensi che si sia tenuto conto
del fatto che siamo in presenza di sistemi M/M/1, M/M/n o altro
(e si parla di server all'interno di reti telefoniche, ovvero 
quelli forse piu' calzanti per applicare la teoria di cui sopra) ?
Te lo dico io come sono state dimensionate le code: 
Uhm...Ehmm... qui secondo me una coda con dimensione massima
di 100 pacchetti e' sufficiente (tieni presente che
chi ha fatto  questa cosa erano sia laureati che non)
... OK va bene cosi' (e giu' a scrivere il codice). Poi si prova
a spedire un centinaio di pacchetti e si vede quanti se ne perdono 
"se ne sono persi 8 ? Quanto era la perdita accettabile per il cliente?
10 ? OK => il sistema funziona!".
Questi sono i metodi che si applicano alla maggior parte dei
sistemi.
Non ti piace ? Nemmeno a me.
Pensi che non sia professionale ? Anch'io.
Ti pagano per fare qualcosa di diverso da questo ? Tipo fare il
calcolo teorico del numero medio di pacchetti in coda, il tempo
medio di permanenza dei pacchetti nel sistema , ecc. Beato
te!! Tieniti stretto il lavoro che hai.
In particolare quel server li' non l'ho fatto io ma se
l'avessi fatto io probabilmente avrei ragionato (mio malgrado)
come ha ragionato quel tizio li'.
Qui si e' pagati per fare un server che perda meno di 10 pacchetti su
100 (perche' il cliente vuole che ne perda meno di 10/100) e farlo
"per ieri".
Non hai calcolato il numero medio di pacchetti in coda ? 
Sticazzi! Non interessa niente a nessuno.
Ti metti a calcolare il numero medio di pacchetti in coda e dici
mi serve una settimana in piu' perche' devo calcolare il
dimensionamento teorico del sistema ? "No... Sei pazzo... non perdere
tempo con queste cazzate... ecc.ecc."
Non ti piace ? Nemmeno a me, ma mi pagano per lavorare cosi'.
Se chi mi paga (ovvero quelle menti esimie uscite da quei processi che 
tu citavi sopra, ovvero il frutto di anni e anni di studi e 
pubblicazioni su IEEE computer transaction), 
mi paga per ragionare cosi' io devo fare  cosi', anche se non mi piace.
Se poi pensi all'esempio del simulatore motociclistico... vedi tu.


 suoi gusti :-)
use case sicuramente e class diagram che ci vuole ben poco per tenerlo 
aggiornato, altri schemi più laboriosi solo dove serve e la bravura di 
chi usa UML, come per tutte le cose, è soprattutto nel capire quando 
serve e quando no e in che modalità :-)


 Se poi pensi all'esempio del simulatore motociclistico... vedi tu.
bellissimo progetto quello, grande esperienza!
