On 6 Feb, 04:21 pm, [EMAIL PROTECTED] wrote:
La mia esperienza � quella espressa all'inizio. Non esiste dire che
l'UML fa schifo. Come non ha senso dire Java fa schifo, Perl fa schifo,
il minestrone fa schifo. Come gi� detto ci sono diversi campi di
applicazione. Personalmente l'ho usato solo *una* volta, e con
profitto,
durante lo svolgimento del tirocinio. Tutte le altre volte (siti web e
robe del genere) mi sono fatto due pallini a penne in un foglio e ho
risolto egregiamente.
Non capisco perche` non si possa dire che qualcosa faccia schifo. Magari
non lo faceva quando e` nato ma con l'evoluzione inizia a fare schifo o
a essere inadatto un po' per tutto. D'altronde se pure i Javisti stanno
cercando un sostituto di Java con Scala un motivo ci sara` credo.
Diverso e` il discorso se sia o meno una cosa che fa schifo a te, nel
senso
che se a te basta Java allora siamo tutti contenti. Ci sono persone a
cui
Java non piace ma non per partito preso, piuttosto perche` l'hanno
usato,
poi hanno imparato altri linguaggi e hanno visto che riuscivano ad
essere
piu` produttivi per fare sostanzialmente qualsiasi cosa e allora la
conseguenza e` che ad oggi il linguaggio vecchio non sia piu` adatto.
Poi
si puo` provocare un po' dicendo che fa schifo.
Qualuno ha fatto notare che "If the implementation is hard to explain,
it's a bad idea;". Ma purtroppo la mondo esistono cose complicate da
spiegare a voce e/o con codice vario. Se devo fare un'applicazione che
regola il braccio meccanico che esegue un'operazione laser sugli occhi,
l'UML serve.
Diceva Einstein che hai veramente capito una cosa solo quando riesci a
farla capire anche a tua nonna. Devo ancora conoscere un argomento che
non si possa imparare facilmente nel suo concetto. Sono riuscito a
spiegare
come funziona un JIT a una dottoressa di lingue orientali, penso di
poter
riuscire a spiegare come funziona un'applicazione che esegue
l'operazione
laser sugli occhi.
Resta oscuro il motivo per cui UML porterebbe a software piu` robusto e
con meno bachi. Da quando il livello di dettaglio di UML e` tale da
impedire
i bachi?
Prima di tutto potrei non sapere che linguaggio di programmazione
usare:
Capo: "Hey tu? Ci serve un programma che permetta di utilizzare questo
fantastico dispositivo "embeddato" all'interno di un vibratore che
regoli la frequanza degli impulsi."
Io: "Ah, si ok, in cosa lo scrivo? c, c++ o turbo pascal?"
Capo: "Non lo so, non ci � ancora arrivato, per� mi assicurano che � a
oggetti"
E` a oggetti cosa significa? Il vibratore e` un oggetto non e` a
oggetti.
Io: "Hey! Ma se non è ancora arrivato come faccio a sviluppare
qualcosa?
Ho il codice?"
Capo: "Col cazzo, eccoti gli schemini UML. Tu devi estendere la classe
"Vibro" implementando qualcosa per la regolazione dell'intensit�"
Non funziona cosi`... Nei dispositivi embedded ci sono una serie di
problemi
di basso livello che vanno affrontati altro che UML. Se quando ti arriva
l'amplificatore scopri che invece di 2MB di EPROM ce n'e` solo la meta`
cosa
fai col codice che hai scritto? Lo butti via, altro che UML. Se quando
arriva
scopri che non puoi usare glibc (per dire) ma devi usare tiny-libc-from-
vattelapesca-srl il codice lo puoi buttare via. Se quando arriva... (e
via dicendo, ci sono un milione di problemi nelle tecnologie
embedded, che mica per niente si chiamano embedded visto che software e
hardware sono mortalmente accoppiati).
Quindi mooolto prima che inizi l'implementazione, tutti i diagrammi
vengo analizzati da diverse persone, in diretto rapporto con il
commitente e con esperti del settore, ad esempio medici e ingegneri
biomedici. Perci� il progetto subir� svariate modifiche. Iniziare a
scrivere codice ora, sarebbe una cosa piuttosto noiosa. Dato che molto
di esso verr� cancellato e/o profondamente modificato.
E` assurdo ragionare di architettura quando non hai la piu` pallida idea
di quello che potrai farci sull'hardware che ti danno. Nel campo
embedded
la sperimentazione e` fondamentale, UML non aiuta.
Tanto peggio e` il pensiero di aver realizzato qualcosa avendo scritto
un
diagramma UML. L'UML e` un disegno, anche quando lo traduci in codice
hai
solo lo scheletro, nessuna funzionalita` e niente di niente.
Mentre scrivi codice sarai COSTRETTO (perche` capita sempre) a cambiare
architettura e se ogni volta devo tornare a UML l'iterazione inizia a
impiegare settimane invece che minuti.
Poi supponiamo che questo software si faccia. E che il braccio
meccanico
regoli male l'intensità del laser decapitando il paziente e
distruggendo
l'intera ala ovest dell'ospedale. Di chi � la colpa? Si prendono
specifiche, progetto UML e implementazione. E si controlla se il
progetto rispetta le specifiche, e se l'implementazione rispetta il
progetto.
Come fa l'UML a stabilire in che modo viene regolata la potenza del
laser?
Se nel codice il programmatore ha scritto:
laser.power = input_from_user + MegaWatt(2000)
UML ci puo` fare davvero poco. Detto questo, e anche se la cosa e` nota
e l'ho ormai ripetuta mille volte, pensare di riuscire a garantire il
funzionamento
di qualcosa senza aver scritto il codice che la fa funzionare (perche`
al
massimo UML e` uno scheletro) e` ridicolo e fa a gara con quelli che
dicono
che la tipizzazione statica aiuta ad evitare gli errori dopo che
l'ariane
e` esploso a mezz'aria per colpa di una conversione tra numeri.
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
