Lezione 1 Ingegneria del Software PDF

[Musica] benvenuti alla seconda lezione di ingegneria del software nella prima lezione di ingegneria del software abbiamo visto e quali erano qua della cosa l'ingegneria del software abbiamo cercato di capire che cosa vuol dire qualità e quali sono alcune delle qualità interessanti dei prodotti soft...

[Musica] benvenuti alla seconda lezione di ingegneria del software nella prima lezione di ingegneria del software abbiamo visto e quali erano qua della cosa l'ingegneria del software abbiamo cercato di capire che cosa vuol dire qualità e quali sono alcune delle qualità interessanti dei prodotti software oggi parleremo di principi parleremo cioè di quella che è la parte centrale importante della nostra disciplina come sapete ho come immaginate l'ingegneria del software e più in generale la maggior parte delle discipline moderne stanno evolvendo e si evolvono in maniera molto rapida e quindi tante cose tante tecnologie età anche tecniche invecchiano presto scoprirete che nei prossimi anni molte alcune delle tecniche che avete in parte nel corso di questi corsi di studi non saranno più altrettanto utili come possiamo diventare anno vecchie ecco i principi sono quello che vi servirà tra 40 anni i principi sono cioè quegli elementi fondamentali che non sono tecnologici che non sono legati in particolare tecnica ma che vi raccontano che cos'è il cuore o quale la mettete usiamolo per misurare l'intera disciplina e la lezione di oggi si articola in due parti cominceremo vedendo cos'è un principio dell'ingegneria del software quindi cercherò di farvi capire un cos'è un principio rispetto a quelli che sono metodi tecnologie strumenti e poi cercheremo di vedere alcuni dei principi fondamentali dell'ingegneria del software cerchiamo di capire che cos'è un principio dell'ingegneria del software il modo più semplice per capirlo e posizionarlo rispetto al mondo in cui stiamo lavorando quindi noi abbiamo se volete un mondo che possiamo vedere fatto a cipolla in questo concetto e abbiamo all'interno di queste cipolle i principi i principi sono quegli elementi che mi dicono quanto una tecnica ma tecnologia una un approccio può essere interessante milano le linee guida fondamentalmente mi dicono per esempio astrazione mi dicono cioè importante estrarre dei dettagli ma non mi dicono come e quei principi sono se volete nascosti dai metodi sono implementati dai metodi se volete meglio quando parliamo di principio di astrazione e noi prendiamo prendiamo e diciamo ok questo metodo è meglio di quest altro metodo per che implementa meglio princi per l'astrazione metodi e tecniche quindi noi abbiamo diversi tipi di approcci che mi permettono di risolvere dei problemi che sono soluzioni sono soluzioni che si basano sui principi quindi mi dicono per esempio fai una certa fase in un certo modo ecco il principio miri descrive il modo in cui ha fatto una certa cosa il metodo la tecnica e l'applicazione del principio a una particola particolare problema metodo i principi metodi e tecniche sono poi incluse nelle metodologie e quindi quello che abbiamo come passo successivo è che abbiamo un insieme di metodologie che mi dicono come articolare come integrare come sistemare diversi tipi di principi quindi quello che noi facciamo rimetto di tecnico noi facciamo e prendiamo una tecnica due tecniche 10 tecniche 10 metri li mettiamo in un contesto particolare e quindi non si tratterà semplicemente di qual è la gara e metodo della tecnica per analizzare le specifiche quella tecnica per progettare quale la peta la tecnica per di code comporre in moduli ma dalla tecnica per verificare la correttezza di un certo tipo di grado di argomento ma più in generale quello che andremo a fare e andiamo a cercare di capire quando applicare quali tecniche come metterla insieme queste sono le metodologie e le metodologie sono loro volta integrate in gli strumenti che ci danno l'opportunità di automatizzare e le diversi tipi di metodi di metodologie di metodi e di tecniche fate attenzione quando parliamo di una cipolla non volevo darvi l'impressione distorta che questo oggetto sia in qualche modo auto contenuto e che sia a livelli nascosto con l'altro è a livelli progressivamente più evoluti e quindi non è vero che noi facciamo ingegneria del software con gli strumenti senza con sé le metodologie metodi e principi quello che è vero è che noi andiamo a utilizzare strumenti con gli strumenti utilizziamo delle metodologie che descrivono come con come raccogliere come coordinare e mettere tecniche e metodi i quali implementano i principi quindi oggi poi adesso passeremo a capire quali sono i principi ma è importante aver capito a questo punto che stiamo parlando del cuore dell'intera disciplina quali sono i principi fondamentali dell'ingegneria del software cerchiamo di capire alcuni di questi principi il primo rigorosità e formalità cercheremo di capire qualche cosa vuol dire poi più avanti diciamo è la formalità nell'approccio e nella risoluzione dei problemi per adesso però vediamo l'elenco dei trinci che poi cerchiamo di capirli uno ad uno secondo separazione dei problemi capacità di separare un problema complesso in problemi molto semplice terzo modularità cercare di identificare moduli che risolvono alcuni particolari elementi e che possono essere usati e integrati quarto astrazione capacità di estrarre dai dettagli quindi di pensare in modo astratto senza vedere l'intero sistema previsione dei cambiamenti capacità di anticipare di prevedere quali sono i cambiamenti e infine inc regione rarità capacità di ragionare nel generale non è particolare e infine incrementali ta capacità di passare passo passo a risolvere i problemi in modo incrementale ecco io volevo proporvi una riflessione che però farete offline non la farina faremo qui a lezione leggete questi principi pensate all'ingegneria in generale quindi non limitatevi un ingegnere del software pensate per quanto sia di vostra competenza come un ingegnere meccanico bisognerà e di nominare civile va a risolvere un insieme di problemi e cercate di capire quali di questi principi vedete implementati in altre tecniche e innanzi tipi di approcci ingegneristiche non è un una vostra competenza specifica necessariamente però un esercizio utile cercare di capire per esempio come nella costruzione di un automobile andiamo ad avere più o meno incrementali ta più o meno astrazione più o meno modularità questo ci permette di capire che quando parliamo di principi parliamo di ingegneria del software parliamo di specifici di principi che sono specifici per ingegneri del software ma molto spesso applichiamo principi che sono anche più generale che possono andare al di là e quindi parliamo proprio di ingegneria vediamo adesso uno per uno questi principi principio numero 1 rigorosità e formalità l'ingegneria del software è una pratica è una disciplina che è fondamentalmente legata alla creatività umana quindi è una disciplina che è legata alle persone non è una disciplina meccanica automatica non è una disciplina in cui le persone sono sostituite dagli strumenti e dai passi automatici ai sistematici ma è una disciplina che richiede sistematicità quello che noi vogliamo fare è non togliere dal cerchio dal look come si dice l'uomo che diventa è che resta e rimane sempre l'elemento essenziale ma vogliamo migliorare amplificare le capacità umane la creatività umana con una serie di elementi sistematici quindi rigore e formalità sono non la sostituzione della creatività umana ma sono il complemento della creatività umana quindi creatività umana vuol dire essere in grado di trovare una soluzione rigore e formalità vuol dire essere in grado di trovare quella soluzione di esprimere in un modo che sia rigoroso e formale per poterci ragionare sopra pensate alla matematica la macchina non si istituisse non si sostituisce al matematico il matematico in grado di fare cose che la macchina non sa fare ma la la formalità il rigore della della forma matematica permette all'uomo di amplificare quella sua creatività e di comprendere fino in fondo quello che sono i risultati che sta ottenendo a quella stessa cosa vale per l'ingegneria del software per quanto possibile cerchiamo metodi e tecnici che siano rigorosi e per quanto possibile formali dove formale se volete un passo ulteriore quindi cerchiamo di capire quando parliamo di rigore formalità non vuol dire che da adesso in avanti ragioneremo soltanto in termini di metodi formali non ne vuol dire che da adesso in avanti ignoreremo tutta quella che è la pratica informale guarderemo soltanto la pratica formale vuol dire che nella pratica che questa è questa posta possa essere formali e informali non ci interessa ma nella fatica cercheremo di essere sistematici e rigorosi e quando possibile anche formare per esempio esempi di applicazione o di implementazione di questo principio di rigorosità e formalità sono per esempio la prova formale di correttezza cioè la capacità o confronto con le tecniche che permettono a un a un ingegnere del software di provare formalmente che a un certo tipo di algoritmo e oggi il problema risponde un di soluzione risolve esattamente un certo tipo di problema quindi quando parliamo di prova a formare di correttezza andremo a specificare in modo formale il problema e andremo a cercare di provare che quella soluzione risponde lo soddisfa il problema l'abbiamo visto nella prima lezione che la correttezza non ci interessa non è un aspetto importante quasi mai ci sono casi in cui è importante quindi per ora fa male di correttezza e la si fa per esempio per un protocollo di comunicazione perché per un protocollo di comunicazione è un pezzo di software piccolo è un pezzo di software piccolo che si può quindi provare formalmente perché si può descrivere in maniera molto rigorosa la descrizione di un protocollo formale di solito viene fatta in modo formale e l'implementazione non è un'implementazione di milioni di linee di codice ma è molto piccola ma allo stesso tempo e uno stop che è estremamente critico nel nostro sistema un errore del tcp ip potrebbe portare un errore dell'intera internet quindi dell'indy miliardi di macchine collegate in internet e quindi prova formale di correttezza non era tecnica principe che andiamo poi a verificare i sistemi ma una tecnica è sicuramente importante che ci dà un esempio chiaro di implementazione di formalità altro esempio di formalità e documentazione precisa è importante e documentare più o meno con più o meno attenzione con più o meno estensione i vari progressi vari risultati che otteniamo nel nostro sviluppo quindi è importante documentare bene i progressi che uno sviluppo però attenzione quando parliamo di documentazione possiamo scrivere una documentazione in formato scritta secondo le nostre i nostri desideri nostro gusto oppure possiamo seguire delle precise linee formali e rigorose non vuol dire che scriviamo la documentazione in algebra ma vuol dire che usiamo delle foto delle delle forme che sono ben 3 c ben definite che ci permettono di semplificare la comunicazione non vedremo molto in questo corso me lo vedrete in altri corsi e se avete occasione la presa e sicuramente sul mondo lavorativo con andato a lavorare in un'azienda che lavora bene non dico un'azienda certificata al massimo ma un'azienda che lavora bene scoprirete che ci sono dei precisi moduli per scrivere la documentazione che comprendono delle sezioni specifiche comprendono dei capitoli specifici che comprendono delle regole specifiche questo vuol dire rigore vuol dire fondamentalmente non necessariamente scrivere in algebra ma vuol dire scegliere un approccio rigoroso e sistematico che permette all'uomo alla creatività umana di essere espressa in maniera più facilmente comunicabile interpretabile e condivisibile quindi realmente di aumentare e di enfatizzare i risultati della creatività umana secondo principio separazione dei problemi questo è un principio che molto spesso viene presentato con il la formula latina divide et impera che è il punto il principio che si prende dagli antichi e quello di separare i problemi per gestire la complessità che cosa vuol dire vuol dire che noi quando andiamo affrontare un problema complesso e noi parliamo di noi esseri umani abbiamo una mente limitata siamo in grado di comprendere e di risolvere di prendere in di vedere un intero problema nella sua interezza nell'istituto i suoi dettagli il fino a un certo livello di complessità oltre un certo livello di complessità non siamo più in grado di vederlo noi andiamo a vedere un sistema operativo e chiediamo vi chiede di parlare con qualcuno che conosce tutti i dettagli del sistema operativo non esiste questa persona non esiste perché è impossibile prendere in considerazione tutti i dettagli di un elemento così grosse quindi questo è un limite intrinseco della mente umana non è un fattore diciamo di fiume in più o minore maggiore o minore capacità un limite intrinseco che vogliamo superare come lo possiamo superare tutte le volte che l'uomo deve andare a sviluppare un sistema complesso lo riesce a risolvere in maniera efficace dividendole in sotto problemi più semplici che sono di che sono risolvibili singolarmente gli ho fatto l'esempio del sistema operativo prendiamo una persona andiamo in produttori di sistemi operativi chiariamo di qualcuno che conosca tutti i dettagli non c'è nessuno provate ad andare nel costruito da un costruttore di automobili credete che conosce tutti i dettagli nessuno ci sono esperti della parte motoristica esperti della parte dinamica esperti della parte meccanica esperti della parte strutturale e nessuno conosce tutti i dettagli quindi qualsiasi processo con il prodotto ingegneristico viene risolto in maniera efficace dividendolo in in elementi e capite che questa non è una tecnica una metodologia ma è un principio un principio che può essere applicata in modi diversi dividendo la macchina in parte meccanica in carte motoristiche in parte statiche dividendo un edificio in parti strutturali e degli interni dividendo il software in base di dati in logica di business e presentazione dividendo un sistema operativo in diversi livelli ciascuno dei quali astratto rispetto agli altri e quindi diciamo la separazione dei problemi è un principio importante e fondamentale di tantissimi aspetti dell'ingegneria per esempio abbiamo fatto che ha fatto l'esempio del sistema operativo la struttura del sistema operativo modo chiaro e preciso per capire come si può dividere un problema complesso in tanti piccoli problemi qui abbiamo altri diversi altri esempi per esempio diverse fasi del processo prendiamo un prodotto abbiamo fatto ad esempio sistema operativo continuiamo con questo esempio la costruzione di un sistema operativo richiede anni e richiede decine di persone centinaia di persone che lavorano assieme quindi richiede un processo estremamente complesso quello che andiamo a fare è dividiamo il processo in fasi dividiamo le fasi in attività di vediamo le attività in sotto attività e questo è un modo per riuscire a gestire questa enorme complessità che sarebbe altrimenti ingestibile se volessimo risolvere il problema tutto in un botto solo quindi quello che faremo e distingueremo varie fasi dentro le fasi l'estremo le varie gruppi di attività e così via proprio per risolvere il problema applicando il principio fondamentale che è quello di sapere di piacere per azione dei problemi oppure un altro tipo e di esempio classico è quello di test e se voi andate a vedere come viene fatto il test lo studieremo in parte in questo corso il test divide in test mita in testa integrazione in testa il sistema in testa citazione e così via cioè le varie fasi sono fasi che hanno tutte lo stesso scopo verificare collaudare il nostro sistema lo facciamo in varie facile poter gestire la complessità dei dati del sistema quindi noi andremo a testare di volta in volta pezzi diversi per potere nella complessità della sua inter ita andare a vedere o sua interezza andare a vedere l'intero sistema altro principio importante e modularità dividere il sistema in pezzi più semplice attenzione abbiamo due gare due cose che sono abbastanza simili ma non è esattamente la stessa cosa da una parte abbiamo la separazione dei problemi dividiamo un problema problema in sotto problema l'altra parte è la modalità della soluzione che non è sempre la stessa cosa qui parliamo di essere in grado di dividere il sistema in moduli quando parliamo di moduli non è necessario non è importante aver diviso il sistema in piccoli elementi il problema insomma in sotto problemi ma è quello di avere diviso un sistema i moduli che hanno due caratteristiche fondamentali alta coesione basso accoppiamento quindi quando parliamo di sistema di modalità cerchiamo di capire che cosa vuol dire che questo è un tipo di esempio i pallini rossi che vedete sullo schermo rappresentano vari sotto problemi e linee tra i vari pallini rappresentano le relazioni tra questi vari elementi e il rettangolo i rettangoli di più chiari che vedete sono alle spalle dei vari pallini rappresentano una possibile modularizzazione quindi andiamo in questo caso tre moduli che astraggono che raggruppano da tre a quattro diversi elementi di basta con una vita ecco questo è un sistema che si dice da l'altro accoppiamento perché è l'alto accoppiamento come facciamo a saperlo contiamo i link tra i vari moduli un modulo ed alto accoppiamento quando ci sono vari link tra i vari moduli quindi diciamo in questo caso avete visto che abbiamo diviso un sistema senza semplificarlo perché perché i moduli sono tra loro stretta e strettamente correlati e quindi non possiamo sempre implementare un modulo rispetto rispetto agli altri o semplificarlo rispetto agli altri vediamo invece che cosa vuol dire bassa accoppiamento prendiamo anche qui un insieme di nodi i puntini rossi sullo schermo prendiamo anche qui un insieme di relazioni arti tra i puntini rossi prendiamo anche qui un insieme di moduli vediamo che le relazioni tra i moduli sono molto più piccole e quindi abbiamo diviso il sistema in modo da minimizzare le relazioni tra i moduli e massimizzare le relazioni all'interno dei singoli moduli questo vuol dire fondamentalmente che io posso sviluppare i singoli moduli osservando e studiando bene delle relazioni complesse che ci sono i tra i vari moto ai vari elementi all'interno del modulo ma limitandone conoscere poco o niente della relazione tra i vari moduli ovviamente voi direte beh a questo punto andiamo all'estremo e costruiamo un sistema in cui vari moduli sono completamente non accoppiati perché il non accoppiamento e non è la proprietà qui andiamo attendere che vogliamo perché esiste i moduli sono non accoppiate non abbiamo più un sistema abbiamo tanti sistemi che convivono in modo in modo indipendente quindi se manca qualsiasi la relazione tra i vari moduli e quello che faremo è facciamo un passo indietro attenzione il problema che stiamo risolvere non è un problema ma sono più problemi cerchiamo di risolvere ciascun problema in modo completamente indipendente se noi andiamo a sviluppare una macchina e un una roulotte evidentemente la relazione tra i moduli non esiste qui realtà esiste c'è il gancio però diciamo sostanzialmente non esiste perché sono due sistemi che sono completamente indipendenti voi costruito una macchina a prescindere dal fatto che possa tornare un clown i conti entrare o meno quindi nessuno si mette a progettare una macchina con il traino ok prendiamo la batte la macchina che un modulo semplice quindi se noi vogliamo fare un sistema gestisce il personale interno universita e che gestisce gli esami dell'università nel momento in cui non c'è alcuna relazione tra personale ed esami questo può essere possibile o meno ma se non ci dovesse essere nessuna relazione stiamo sviluppando due diversi sistemi quindi se noi andassimo a identificare due moduli senza nessuna relazione abbiamo un basso copiano la diamo un basso coppia mente noi abbiamo due sistemi completamente diversi che non vanno sviluppati insieme vanno sviluppati in maniera indipendente quindi quello che noi cercheremo di fare e questo è un buon principio che vi permette di distinguere ogni volta come se lo fate bene o male sarà quello di raggruppare con i distinguo e nel problema nella sua interezza moduli diversi che siano il più possibile disaccoppiati quindi massimizzeremo all'accoppiamento all'interno di un modulo per renderlo più basso all'interno e all'esterno dei moduli è qui tra i moduli stessi altro principio estremamente importante e non unico dell'ingegneria del software e l'astrazione astrazione vuol dire né l'unico esempio ignorare i dettagli quindi quello che vogliamo dire quando parliamo di astrazione vogliamo dire prendiamo l'astrazione e prendiamo un sistema e ignoriamo completamente quelli che sono i dettagli vi faccio degli esempi li faccio vedere un caso per specifico che forse molto più chiaro esempio equazioni differenziali per descrivere i circuiti un circuito è pieno di dettagli non so quanti di voi conoscono i circuiti bene io no però diciamo qualcosina li conosco prendete un circuito ed è estremamente difficile da capire prendiamo un'equazione differenziale non so quanto voi cominciate le equazioni differenziali ma certamente l'equazione di rehn differenziale non comprende tutti i dettagli di un circuito ma soltanto alcuni elementi quindi equazione differenziale vuol dire fondamentalmente io non ragiono sull'intero circuito sul quale non posso ragionare ma prendo il modello del circuito a strand un insieme di dettagli che non mi interessano per quel tipo di ragionamento quindi attenzione l'equazione di differenziare non sono il circuito sono un'astrazione del circuito io la strago da alcuni elementi per esempio strago dalla distanza tra le piste estraggo della di una dimensione delle piste estraggo da un sacco di cose che sono assolutamente importanti rilevanti nello sviluppare un circuito perché non potete ignorare per esempio la posizione delle piste sulle vostre schede per poter avere un circuito e funzionante in maniera ma possiamo ragionare su alcune proprietà astraendo da questo e guardando soltanto in relazione che è descritta per esempio in termini di equazioni differenziali equazioni differenziali che potete dirmi sono difficili certamente ma sono più facili mi permettono di ragionare meglio rispetto al circuito in quanto tale ecco questo è l'astrazione la premessa per quello che è l'elemento essenziale dell'ingegneria del software che sono i modelli quindi noi quando ragioneremo ragioneremo e si ragiona sempre di più anche in campo industriale in termini di modelli oggi il trend principio dei tre principali della ricerca quello che si chiama model based software engineering cioè ingegneria del software basata su modelli si sta cercando di estrarre completamente da alcuni elementi che vengono resi meccaniche per ragionare i meccanici per ragionare in maniera completa e consistente su modelli quello che si fa già per esempio nell'art ok io credo che nessuno di noi sia così in haiti da pensare che ci sia qualcuno che con una riga un compasso a disegnare i circuiti quello non viene più fatto dall'uomo ok non vuol dire che l'uomo è stato sostituito nella sua creatività vuol dire che la crescita e creatività umana è riuscita a meccanizzare automatizzare un insieme di passi che non richiedono l'intervento umano per permettere la mente umana di concentrarsi sugli aspetti difficili del problema che sono le equazioni che rappresentano il funzionamento del circuito nel caso di circuiti di circuiti logici nel caso invece di software quello che facciamo e quello che cerchiamo di fare io abbiamo già fatto è astrarre progressivamente dai dettagli l'abbiamo fatto negli anni sessanta e settanta estraendo dalla struttura della macchina stessa con i sistemi operativi l'abbiamo fatto strand dal dei linguaggi macchina con i compilatori lo abbiamo fatto costruendo linguaggi sempre più astratti e sempre di nuova generazione se dice cioè sempre meno legati al dettaglio di funzionamento della macchina e lo vogliamo fare lo stiamo facendo ora nella ricerca al mondo della ricerca lo vedete fatto nel mondo del lavoro tra qualche anno a straremo completamente dai linguaggi di programmazione ci sarà un giorno sono convinto in cui non andremo più a scrivere in qualsiasi linguaggio di programmazione ma andremo a modellare ea proporre a produrre il codice direttamente dal modello con tutto quello che ne consegue in termini di capacità per esempio di affrontare sistemi di dimensioni molto più grandi tenete presente che la stazione viene spesso con la capacità o la necessità di affrontare problemi di dimensioni sempre più grandi se io vi chiedessi di ragionare sul sulla correttezza di un sistema operativo senza alcun tipo di astrazione non riuscireste a fare nulla ma se cominciamo a ragionare sulla corsa cominciamo a lavorare sulla gestione della memoria e sulla gestione dei processi sulla gestione dei driver allora riusciamo di volta in volta a ragionare su un aspetto del sistema astraendo da altri aspetti ragionando sul modello di quella spetta e questo si chiama astrazione ecco un esempio lo vediamo sullo schermo e vedete una cosa che è quasi illeggibile incomprensibile e non mi interessa che la leggiate questo è il sistema in tutti i suoi dettagli se anche velo proiettarsi con un cane un font più grande e non lui si veste leggere molto di più perché perché abbiamo un pezzo di codice che nel momento in cui diventa più lungo di poche centinaia migliaia di mini di codice diventa difficile da leggere perché perché vogliamo leggere tutti i singoli dettagli sono certo che se io vi chiedessi cosa fa questo software resto in grado con un certo tipo non per un po di tempo di capirlo e farlo funzionare però faccio vi faccio vedere quest'altra cosa e questo è lo stesso software no non è lo stesso software è un modello del software se vi chiedo che cosa fai sorta in questo momento la risposta viene molto più immediata questo software implementa un sistema ha fatto a tre stati che si chiamano cd che indicano uno stato di non presente il componente non è presente non è legato è legato ci sono delle transizioni per ragioni di visualizzazioni non vi faccio vedere tutte le etichette ma vi aggiungo abbastanza informazione sul modello ve la posso aggiungere ed è quella che vi do la voce per farvi capire esattamente cosa come e fatto il sistema quindi questo è un modello astratto quello che abbiamo visto precedentemente è il modello è il sistema in quasi tutti i suoi dettagli avrei potuto proiettare il codice binario evidentemente quindi passando dal codice binario al codice java abbiamo un salto di qualità in termini di astrazione codice java non vi fa vedere tutti i dettagli del codice binario è un piccolo passo verso un modello più astratto e un modello del codice binario un modello che in questo caso corrisponde uno a uno con il codice binario partito di scenario è generato dal programma java è un livello di astrazione che vi permette di ragionare in maniera molto più efficace tornando e spero che vi ricordiate ancora come si sa come si scrive un programma java e lì spero che sia chiaro a tutti che ragionare a livello java è abbastanza dettagliato ma è molto meno dettagliato a ragionare a livello binario e anche se non conoscete bene il problema della programmazione binaria allo stesso modo spero che sia chiaro a tutti che se io vedo che deve scrivere il funzionamento di un componente con questo modello riesco a farlo in maniera molto più efficace rispetto al modello java perdo una serie di elementi per esempio non sapete quanti sono i metodi non sapete quali sono i metodi non sapete qual è quali sono i parametri dei metodi non sapete quali sono le variabili globali e locali interne ed esterne che sono utilizzate non avete le regole di visibilità del codice quindi non è il codice è un modello che per me vi permette di ragionare sul codice questo vale per un sacco di altri tipi di modelli quindi estrarre vuol dire dimenticare alcuni elementi per metterne a fuoco solo altri che ci permettono di ragionare meglio ci permettono di fare delle prove di tali di trovare deve fare delle congetture di correttezza di lavorare su su un sistema più consistente come nel caso dei moduli anche l'astrazione c'è quella buona e quella cattiva astrarre non vuol dire dimenticare qualsiasi tipo di dettaglio e la grande capacità dell'ingegneria del software la grande capacità umana e quella di essere in grado di capire quali sono i dettagli da cui possiamo estrarre per capire quali sono gli elementi su cui ci dobbiamo concentrare io portavo una moderna astratto e un modello che invece di prendere tutti gli identificatori di un programma già va bene soltanto la prima lettera questa è un'astrazione è un'astrazione assolutamente inutile nel settore assolutamente inutile perché non mi dice niente di più anzi mi dice di meno e in peggio rispetto a dovrà mangiava mentre se io guardo questo tipo di sistema io osservo ci sono tre stati quindi o delle informazioni mi concentro su cosa in questo caso sul comportamento a stati del mio programma ignorando altri tipi di dettagli implementativi che in questo momento per questo tipo di ragionamento non mi interessano non solo astraendo dal programma posso dire delle cose che sono sostanzialmente e difficili e da pensare sul programma stesso costruitevi modello fallimentare di un programma java che realizza un sistema tre stati e vi chiedo è completo cioè vi chiedo ciascun metodo è gestito in maniera completa in ciascuno stato non è facile da capire guardiamo qui invece contiamo gli archi che escono da ciascuno stato e vediamo di capire con le etichette opportuna e ripeto questo non è il modello finale di servono anche le etichette ma possiamo per esempio scoprire che da nord prese in testa soltanto un arco da unbound escono uno due tre archi da bound escono 12 archi quindi con un po di etichette possiamo per esempio chiederci ma è possibile che i remi che ci siano alcuni alcuni metodi che sono che sono dei gestiti in nello stato al bound e bound e no nello stata una presenza probabilmente sì non so quali ma probabilmente sì ok quindi questo mi permette di ragionare sul modo in cui gestisco i metodi nei vari stati cosa che è molto più difficile nel caso nel caso di codice questo lo ripeterò più volte nel corso di queste elezioni questo è un esempio molto semplice non scaricate il codice cerca di ragionare sul codice perché sicuramente riusciti a farlo dovete proiettare questo su un esempio completo se io qui avessi i 50 stati e il codice corrispondente diventa molto più complesso fare qualsiasi tipo di ragionamento sul codice quindi estrarre vuol dire non soltanto rendere più semplice problema che già di suo è semplice perché quali abbiamo visto prima e molto facile molto semplice ma vuol dire essere in grado di gestire pezzi di codice problemi di dimensioni molto più grandi ok io qui posso gestire tre stati ma le posso gestire anche 30 e continuare a ragionarci su una classe java o sono sempre sistema java di essere 30 stati è molto più difficile molto meno immediato altro tipo di principio importante è la previsione dei cambiamenti la previsione dei cambiamenti è la capacità di affrontare l'evoluzione quindi quello che noi vogliamo fare in questo caso è cercare di capire che cosa succederà in futuro quindi e prevedere i cambiamenti può sembrare strano come principio e può sembrare strano anche che sia necessario farlo cerchiamo di capire un esempio e poi cerchiamo di capire anche che cosa vuol dire perché è un principio e perché è importante farlo prendiamo un esempio un esempio di implementazione di questo principio la gestione delle configurazioni cioè un sistema che mi permette di gestire le varie tipi di configurazione che cos'è un sistema di gestione delle configurazioni è un sistema che mi mantiene traccia della relazione tra i vari moduli e tra le quali tale configurazione dei vari moduli e tra i vari vari l'evoluzione dei vari moduli quindi mi dice che nella versione 3.0 è stata modificata dalla versione è stata derivata dalla versione 3 2.95 infatti in funzione di certi tipi di cambiamenti e la versione 2 95 è stata ottenuta modificandola 294 per 294 è compatibile con la versione 293 di un altro modulo e così via quindi sistema di gestione delle configurazioni e un sistema che tiene traccia dei cambiamenti nel nostro sistema quindi già questo mi dice che un principio un principio perché è un un'idea concettuale che poi implementato in una tecnica oppure in un metodo ricordate cosa cos'è un principio ecco che senso ha questo principio come viene implementato beh fondamentalmente questo principio è importante perché il software evolve evolve durante la fase di progettazione e dopo allora prevedere i cambiamenti vuol dire come costruirono studiare un insieme di tecniche di metodologie ed i metodi che permettono in qualche modo di verificare se e in che misura il software potrà essere diverso o potrà essere usato in condizioni diverse questo è estremamente importante perché le diverse condizioni possono compromettere completamente utilità del software quindi possono portare un fallimento piuttosto che a un successo di un di un progetto vi faccio un esempio che deriva dalla mia esperienza ai tanti anni fa ormai una società che conoscevo bene aveva deciso di costruire un sistema per la gestione di studi notarili in quel contesto non esisteva ancora un sistema progettone molti studi notarili ed era un'idea eccezionale tant'è vero che chi poi ha fatto questo sistema è diventato ricco quindi diciamo evidentemente parliamo di un problema ben definito complesso che richiede una soluzione informatica che può essere risolto bene in modo informatico che ha un mercato un mercato che di persone che si possono permettere di pagare per una soluzione di costose questa città cominciato a lavorare nel periodo in cui si utilizzavano mini computer e ha costruito il software per mini computer ahimè per analizzare a fondo prima ci sono voluti alcuni anni perché capite che non è facile capire esattamente tutti i dettagli del funzionamento del nostro di notarile serve interagire con molti notai serve a capire quali sono gli elementi nel contesto dello sviluppo e nel frattempo è diventato importante un sistema si è passati da dei sistemi mini a sistemi persa nel personal computer è diventato più fa più potente sia cominciato a girare tra i personal computer per applicazioni non più soltanto di tipo giochi ma anche di tipo professionale un concorrente ha avuto la stessa idea ma sviluppato su personal computer sono arrivati con un sistema troppo costoso che ahimè non aveva previsto questo cambiamento ambientale e quindi sono falliti sono falliti perché questo tipo di cambiamento non era stato previsto quindi prevedere i cambiamenti e utilizzare tecniche che sia nella fase di processo nella fase di prodotto possono prevedere i cambiamenti è strano sono estremamente importanti per riuscire a affrontare in modo efficace e in modo vincente lo sviluppo del software ci sono moltissimi aneddoti e tantissime storie di progetti falliti per la mancanza di capacità di previsione dei cambiamenti o per tecniche non erano facilmente adattabili ai cambiamenti altro altro sistema o alto principio la generalità che vuol dire risolvere il problema generale e non solo l'istanza del problema che cosa vuol dire vuol dire sostanzialmente costruire una soluzione riusabile vogliamo ordinare soltanto oggetti che rappresentano esami o vogliamo ordinare oggetti che sono ordinabili rispetto a un campo intero è chiaro che la rutino la metodo la funzione che ordina oggetti che sono le che sono ordinabili rispetto a un cambio in campo intero e più in generale dalla routine che ordina esami di laurea perché gli esami di laurea vanno da 1 a 30 perché dalle 18 30 come volete potete esami di laurea perché sono applicabili soltanto a quel tipo the strumento da routine o il metodo che ordina insieme in generale oggetti che hanno rispetto a un campo intero è molto più generale di quella che ordina soltanto gli esami di laurea è chiaro che quella caduti in che ordine oggetti non soltanto rispetto a un campo intero ma rispetto a un qualsiasi campo che abbia una funzione di ordinamento parziale o totale è più generale che non una che ordina soltanto campi interi perché posso ordinare ad esami di laurea per voto ma per data per per numero di opere posizione nel piano di studi e così via e chiaro che una funzione che ordina oggetti rispetto a un campo che può essere un campo di qualsiasi tipo purché abbiano una relazione di ordinamento e lo faccia in modo crescente o decrescente e lo faccia per uno più campi ancora più generali e potrei andare avanti con il campo di generalità quindi più la soluzione generale e più e riusabili e allora facciamo il sistema che fa tutto ecco attenzione proprio questo il punto la generalità è un principio che va applicato come tutti i principi in maniera molto attenta più in generale una soluzione più costa è più facile e meno costoso costruire una soluzione ad hoc kemp che ordina esami perenne considerazione un campo che ha un valore tra 18 e 30 rispetto a una che ordina a qualsiasi tipo di oggetti rispetto a un campo intero rispetto a una che ordina e così via quindi attenzione generalità non vuol dire che la comunità informatica sta lavorando alla soluzione generale che funziona per tutto ma vuol dire che ogni volta che andiamo a trovare una tecnica un metodo una soluzione cerchiamo di capire qual è il livello corretto di generalità per ottenere una soluzione che sia costa effetti che sia quindi riusabile ma allo stesso tempo economica rispetto al tipo di uso che ne vogliamo fare e questo lo vedremo poi o lo vedrete forse in altri con sé quando si parlerà a fondo di riusabilità quando parliamo di riusabilità sarà importante capire che costruire un modulo un elemento di usabile non è sempre importante o decisivo perché la responsabilità viene ha dei costi e quindi c'è il modulo disabile ha senso costruire modo le usabile solo nella misura in cui il modulo verrà poi effettivamente egli usato ultimo principio avevo detto incrementali ta vuol dire procedere a passi successivi allora ogni volta che è possibile è importante procedere a passi successivi nella nostra sola nostra soluzione dei problemi fatemi di darvi un esempio per esempio uno sviluppo per prototipi incrementali lo vedremo nelle prossime elezioni quando parleremo di processi di sviluppo un aspetto importante è quello dello sviluppo per prototipi incrementali che cosa vuol dire vuol dire sostanzialmente che io ho due alternative la prima è quella di sviluppare un sistema nella sua interezza e ottenere un risultato finale la seconda è quella di sviluppare un sistema passivi avere quindi un insieme di prototipi che sono eseguibili nello scorso dello sviluppo ecco lo sviluppo prototipi incrementali e un esempio di implementazione del principio di incrementali ta perché sono più efficaci rispetto a un'unica soluzione finale sono più efficaci perché io posso per esempio andare a verificarli di passo in passo perché posso per esempio con validarli proponendo gli utenti perché posso per esempio ridurre l'ansietà dell'utente e voi pensate al vostro cliente che ha bisogno di qualcosa che definizione in tempo se ogni mese vede un piccolo prototipo incrementale e molto meno ansioso che non si deve aspettare tre anni per ottenere il primo è il sistema funzionante attenzione abbiamo detto prima niente viene gratis lo sviluppo incrementale o comunque l'increment alita viene a un costo evidentemente nel caso dell'esempio di prodotti di incrementali costa e sviluppare dei prototipi incrementali e di costa ed è un uno sviluppo che che può essere o meno in 3d importante a seconda dei compromessi che voglio raggiungere per cui per esempio se lo sviluppatore ha portato di incrementare mi porta o troppi prototipi mi riduce in maniera drastica la città del cliente ma non mi permette di con di consegnare il prodotto finale alla fine non è un buon approccio quindi non necessariamente o non sempre l'applicazione acritica del principio è un buon approccio quindi quando parliamo di apporti i principi ne parliamo esattamente in questa accezione cioè noi abbiamo un insieme di linee guida che ci devono permettere di applicare in maniera costruttiva ed efficace la nostra creatività non vanno mai massimizzati non ha senso cercare in maniera incrementale la soluzione più generale a tutti i problemi quello che vogliamo fare è una soluzione che abbia un grado di incrementali ta sufficiente a risolvere i nostri problemi allo stesso tempo una generalità sufficiente allo stesso tempo una modalità su di sufficiente e così via vediamo così concluso quello che noi abbiamo visto in questa lezione sono i principi fondamentali dell'ingegneria del software abbiamo visto diversi principi che vanno da rigorosità e formalità la separazione dei problemi la modularità ad astrazione la previsione dei cambiamenti a generalità incrementali ta sono i principi fondamentali quelli che conosciamo tutti non sono gli unici principi vi chiederei io vi suggerirei due cose la prima cosa e cercate forse non è con questo corso ma nel corso della vostra carriera di identificare altri tipi di principi se anche una sola volta riuscito a identificare un principio che possa guidare nella scelta delle varie soluzioni questo è molto importante ricordate di questi sono gli elementi che vi permettono di discriminare dalle vostre scelte quindi quando tra quattro anni sarete sul mondo del lavoro e avrete un nuovo linguaggio di programmazione nuova tecnica di specifico nuovo approccio metodologico e meglio o peggio di quello che state utilizzando tornate a guardare i principi e cercate di capire quali principi implementa quali principi di un implementa quali i principi soddisfa e come li soddisfa e avete una risposta molto facilmente che non cercando di capire a scatola chiusa l'ultima raccomandazione è cercate di capire questi principi non soltanto seguendo questa lezione o avendo seguito questa lezione studiando il materiale che vi proporrò ma anche e soprattutto cercando di capire di volta in volta nelle prossime elezioni quando parleremo di varie tecniche metodologie e processi quali principi vengono implementati e perché è perché sono efficaci [Musica] no