On 7 Feb, 02:55 pm, [EMAIL PROTECTED] wrote:
Toh... compare un linguagigo di modellazione per specifiche hardware.
Per l'hardware va bene e per il software no?
Ma e` chiaro... Realizzare l'hardware ha dei costi non indifferenti.
Come pensi di simulare il funzionamento dell'hardware senza realizzarlo
se non hai un modello?
Di contro il software e` estremamente flessibile e non si capisce
perche`
dovrei cercare di irrigidirlo invece di usare una strada che mi permetta
di sfruttarne la flessibilita`.
Per inciso, chiunque abbia competenze di Product Lifecycle Management
sa benissimo quanto sia cruciale per loro l'accorciamento del tempo
di sviluppo di un nuovo prodotto e l'introduzione di strumenti digitali
che rendesse possibile lo studio fisico sul modello virtuale ha ridotto
i costi in modo assurdo. Un modello di automobile per un crash-test e`
capace di costare 2-4 milioni di euro e devono farne parecchi di crash-
test.
Se riesco a fare CAE sul modello riduco il numero di modelli fisici che
dovro` realizzare, potenzialmente portandolo a uno.
L'idea e` chiaramente quella di ridurre il costo del
prodotto e erroneamente viene applicata anche al software. Nel software
non c'e` differenza tra modello e prodotto, sono la stessa cosa.
Realizzare
il modello del modello e` abbastanza inutile se permetti.
Ecco perche` non va bene paragonare le case al software o i prodotti
fisici
al software. Il software NON e` fisico. E` software ed e` di per se` un
modello e un prototipo di se stesso.
C'� una grossa azienda che produce software molto grosso e ha sedi di
tutto il mondo. Essa vende un programma fantastico che però quasi
subito
accusa dei malfunzionamenti. Fatti gli accertamenti del caso, si scopre
che c'� un pezzo di codice che non si comporta a dovere.
Supponiamo poi che il progettista e lo sviluppatore siano persone
diverse (che non � una roba cos� poco diffusa come potreste pensare)
come fa il progettista a discolparsi? Con dei fogli di stampante su cui
ha scritto degli appuntini per lo sviluppatore? O magari affermando
"che
lui gliel'aveva detto al programmatore come si faceva"?
Il progettista non e` molto bravo perche` invece di scrivere dei fogli
di carta doveva scrivere parecchi test di integrazione e
di sistema ecc. ecc.
Il programmatore invece doveva scrivere dei test unitari su cio` che
scriveva.
Non c'e` specifica migliore di questa:
assert somma(4, 5) == 9
A te il compito arduo di scrivere la funzione che ho usato poco sopra.
Poi d'accordo che il progettista non sempre scrive dei test ma nel caso
collabora con chi lo fa (gli ingegneri QA, i deployment engineer e via
dicendo) ed e` in grado di dire quali siano i test necessari e quali no.
Con l'UML _COMUNQUE_ non si sarebbe scoperto che il programmatore
briccone
aggiungeva 1 a tutte le somme e moltiplicava per 3 tutte le differenze.
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
