Re: [Python] Python vs UML
Java ha scritto: > 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? Semplice. Il progettista si prende le sue responsabilità, come tutti. D'altra parte, il suo lavoro si completa dopo aver verificato che quello che ha progettato funzioni. Simone Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 7, 2008, at 3:55 PM, Java wrote: > Toh... compare un linguagigo di modellazione per specifiche hardware. > Per l'hardware va bene e per il software no? E' chiara la differenza fra hardware e software con annessi e connessi? Chiedo perché se lo fosse, dovresti renderti conto che in primo luogo quello che va bene per il software non va bene per l'hardware (aggiungo che, anche se forse nei corsi universitari di Ing Sw non lo dicono spesso che ci sono *grosse* differenze anche nel modo in cui approcciare diversi tipi di progetti software, costi accettabili, defect rate accettabili, tipi di difetti accettabili, tipi e quantità di ritardo accettabile). In aggiunta il punto è che essere 'contrari' ad un dato linguaggio di modellizzazione voglia essere contrario a *tutti*, al concetto di 'modellizzazione' (ivi inclusa quella per ambiti non informatici etc etc etc). Tipicamente l'hardware ha in se e per se un livello di astrazione bassino; viceversa il software non necessariamente. Tipicamente Python ha un livello di astrazione non certamente più basso di UML (per quanto ovviamente un linguaggio di programmazione come Python è adattissimo per esprimere determinati tipi diagrammi UML, mentre altri no -- al che bisogna chiedersi se questi altri diagrammi sono o meno utili, per cui vedere se usare UML per quelli, se usare un altro formalismo oppure se si possono non fare e basta --). Poi si pongono problemi di *costo* di realizzazione. Un prototipo software è direttamente eseguibile (un diagramma UML no). *Costruire* dell'hardware, disfarlo, cambiarlo è costosissimo: con il software molto meno (specie se in un linguaggio in cui i cambiamenti sono facili). Tipicamente fai prima a scrivere un programma in verilog che a bruciarti un PLA (ammesso che il problema che stai risolvendo sia proprio semplice, se no con un PLA vai poco lontano). Etc etc. Comunque io fossi in te mi chiederei se pensi *davvero* che hw e sw siano la stessa cosa. > 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"? Scusa, ma questa è stra-fuffa. E' una situazione ipotetica in primo luogo, sufficientemente generica da voler dire tutto e nulla. Aggiungo che in un caso del genere, i primi a saltare sono quelli del reparto qualità (se esiste), poi quelli del testing (che evidentemente hanno cazzeggiato). Questo sempre nel mondo fantastico dei ruoli distinti e del 15 teste e un senior e 10 neolaureati. Comunque, tornando a noi, dopo averti ringraziato dei tuoi insights sul mondo del software, non posso che ribadire quello che ti fa notare anche Antonio. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
>> Non so chi ti ha dato l'idea del 'codice critico -> UML', >> >> > Nessuno, e infatti non volevo dire quello. Ho solo fatto un esempio a > caso. >> Ma mi chiedo che accidenti di esempi fai. >> > Vedi sopra: è solo un esempio. Esempio che ha una GROSSA somiglianza con gli esempi che fanno nei corsi universitari di ingegneria del software ecc. Nel mondo reale è leggermente diverso... >> Sempre tipicamente, questa roba la modelli in verilog etc >> > Toh... compare un linguagigo di modellazione per specifiche hardware. > Per l'hardware va bene e per il software no? Stai scherzando, vero? O sul serio pensi che hardware e software possano essere trattati alla stessa maniera? > > 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"? Ok, ora è certo: stai scherzando! ;-) 1) La separazione *netta* tra progettista e sviluppatore non è nemmeno così diffusa come puoi pensare. 2) Se un "pezzo di codice" non si comporta a dovere, che gliene può fregare al progettista? 3) Se pure non fosse "un pezzo di codice", ma un errore di progetto, in cosa potrebbe aiutare UML? -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
Aggiungo un indispensabile contributo a questa discussione: avete letto la vignetta su stacktrace? http://stacktrace.it/2008/01/silver-bullets/ ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
> > E' una posizione 'strana'. In primo luogo sono perfettamente convinto > che qualcuno che lavora nell'IT abbia tutto il diritto di farsi la sua > idea su una data tecnologia/metodologia. Questo a prescindere dal > fatto che abbia o meno ragione. > > Ok, ognuno deve farsi la sua opinione, ma non avere la presunzione che questa sia la realtà. Ma: >> Come già detto ci sono diversi campi di >> applicazione. > > Non so chi ti ha dato l'idea del 'codice critico -> UML', > > Nessuno, e infatti non volevo dire quello. Ho solo fatto un esempio a caso. > Ma mi chiedo che accidenti di esempi fai. > Vedi sopra: è solo un esempio. > Sempre tipicamente, questa roba la modelli in verilog etc > Toh... compare un linguagigo di modellazione per specifiche hardware. Per l'hardware va bene e per il software no? > Ah. Ed è necessario l'UML. Faccio notare che se ti schianta una roba > del genere, è per i *parametri* e l'*intensità*, non per il design. > Ammesso che ci sia design. > Siccome era un esempio a caso, allora possiamo ipotizzare di essere sicuri che la colpa sia del software. Anzi visto che risulta complicato astrarre da un esempio pratico, facciamo così: 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"? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python vs UML
On Feb 6, 2008, at 5:21 PM, Java wrote: >> Non mi pare di avere letto alcuna di queste mail. >> Ad ogni modo sono sicuro che portando anche la tua esperienza non >> puoi >> che alzare il livello della discussione. >> > La mia esperienza è quella espressa all'inizio. Io avevo chiesto anche un'altra cosa, in effetti. > Non esiste dire che l'UML fa schifo. Come non ha senso dire Java fa > schifo, Perl fa schifo, > il minestrone fa schifo. E' una posizione 'strana'. In primo luogo sono perfettamente convinto che qualcuno che lavora nell'IT abbia tutto il diritto di farsi la sua idea su una data tecnologia/metodologia. Questo a prescindere dal fatto che abbia o meno ragione. Non solo: qualcuno che lavora nell'IT ha spesso il *dovere* di farsi un'idea su una data tecnologia. Che può anche essere 'fa schifo'. Non è che tutto deve essere 'buono' o 'buonino'. Poi possiamo intenderci sulla terminologia; forse 'fa schifo suona male', ma non è che usando giri di parole si cambi la realtà dei fatti. Si, certo, forse si è meno estremi e tutto. Perchè vedi in questo relativismo in cui il 'fa schifo' non esiste, non può esistere neppure il 'è fatto bene'. Per cui sospendiamo il giudizio e... cosa decidiamo? Forse vogliamo contestualizzare tutto: non diciamo che Java fa schifo; diciamo che richiede hardware classe enterprise[0] per fare quasi qualunque cosa non banale e che è circa 3 volte meno produttivo di Ruby/Python? Wow, così suona molto più pro. Ma se leggi fra le righe cosa ho detto? Che fa schifo. Nota, poi posso anche sbagliare, ma sono semplicemente stato esplicito sulle ragioni per cui non mi piace (esempio), invece che dare la versione corta. [0]: no, non è il vecchio discorso del 'è lento', è il discorso 'ha una gestione della ram allucinante'. > 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. E quindi? Ho anche scritto una piccola libc in asm, ma non per questo direi che è sensato farlo (a meno che -- apresi dibattito su embedded etc etc etc). > 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. Ugh? Ma qui siamo all'assurdo! Fai dell'UML per il codice praticamente macchina del controller del braccio e tutto? Quello è un tipico caso in cui UML serve a *molto* poco; tipicamente non starai nemmeno usando un linguaggio ad oggetti, figuriamoci. Non so chi ti ha dato l'idea del 'codice critico -> UML', ma questa è *totalmente* sbagliata, a prescindere da quello che pensi di UML. UML ha un'altra funzione. E' un linguaggio di *modellazione*: quando hai un problema che *non* richiede modellizzazione, *sicuramente* è lo strumento sbagliato. E scrivere il codice che sopra dicevi ha bisogno di verifiche formali, test molto accurati, whatever. Non di 'modellazione'. Anche perchè quello che fa il braccio, dipende anche e in buona parte dall'hardware, il come lo fa, etc etc etc. > 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." Ma mi chiedo che accidenti di esempi fai. Questa è roba che è grazia ricevuta se ti lasciano usare il C. Sempre ammesso che non sia fatto direttamente con una rete logica + eventualmente un po' di microcodice. Sempre tipicamente, questa roba la modelli in verilog etc > Capo: "Col cazzo, eccoti gli schemini UML. Tu devi estendere la classe > "Vibro" implementando qualcosa per la regolazione dell'intensità" ROTFL. Immagino ci sarà la manovella che chiama setIntensity. Non ho parole. > 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. > > 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. Ah. Ed è necessario l'UML. Faccio notare che se ti schianta
