Alcune immagini sono tratte da: ...moodle.isisfacchinetti.it/file.php/.../65/573/Tecno2_-_L_ingegneria... · ... il cuore della disciplina ... alla messa in opera e alla manutenzione

1

paolo macchi

Alcune immagini sono tratte da: http://www.youtube.com/playlist?list=PLgqAc4E1vc2vxNkgLK6EZXCkBbsaAvwvC

Approfondimenti sono stati fatti basandosi anche su : http://studenti.di3.units.it/Sistemi%20Informativi%20I/Slide%20Progettazione%20%28e%29.pdf)http://www.federica.unina.it/ingegneria/ingegneria-del-software-ingegneria/introduzione-ingegneria-software-2/http://home.deib.polimi.it/morzenti/IngSw/cicliDiVita.pdfhttp://www.uniroma2.it/didattica/ISW1/deposito/03-Requisiti_software.pdf

Tecno2 - L’ingegneria del software – paolo macchi - ISIS Facchinetti rel. 19.02.05

Tecno2L’ingegneria del software

Tecno 2 - l’ingegneria del software – ISIS Facchinetti 2013-2019

http://home.deib.polimi.it/morzenti/IngSw/cicliDiVita.pdf

http://www.federica.unina.it/ingegneria/ingegneria-del-software-ingegneria/introduzione-ingegneria-software-2/

http://studenti.di3.units.it/Sistemi%20Informativi%20I/Slide%20Progettazione%20(e).pdf

http://www.youtube.com/playlist?list=PLgqAc4E1vc2vxNkgLK6EZXCkBbsaAvwvC

2

Questo testo è pubblicato sotto licenza Creative Commons - Attribuzione - Non commerciale - Condividi allo stesso modo 3.0 Unported - Per le condizioni consulta: http://creativecommons.org/licenses/by-nc-sa/3.0/deed.it . Le utilizzazioni consentite dalla legge sul diritto d'autore e gli altri diritti non sono in alcun modo limitati da quanto sopra. Il documento è scaricabile da http://isisfacchinetti.gov.it/ , sezione download http://moodle.isisfacchinetti.it/mod/data/view.php?id=1391 di CIF2.0 http://moodle.isisfacchinetti.it/ , per fini esclusivamente didattici e non commercialiSegnalazioni di errori, critiche e consigli sono molto graditi e possono essere inoltrati a [email protected] , oppure lasciando un commento al momento del download per gli studenti registrati.

Tecno2 - L’ingegneria del software – paolo macchi - ISIS Facchinetti ISIS “Cipriano Facchinetti” via Azimonti, 5 - 21053 Castellanza (VA) - http://www.isisfacchinetti.gov.it/ Tel. 0331635718 fax 0331679586

Convenzioni usate nel testo:

rappresenta una curiosità, un approfondimento NOTA rappresenta una nota

rappresenta una esercitazione o esempio http://qrcode.kaywa.com/ link di riferimentoRappresenta un codice o dei risultati o una segnalazione storica

Indice generale

Indice generale...........................................................................................................................................................................2Perché siamo qui?.................................................................................................................................................................................6

Come avere conoscenza del problema?..........................................................................................................................................6Qualche esempio reale....................................................................................................................................................................8

Cos'è il Software?................................................................................................................................................................................10Costi nel processo di produzione del Software.............................................................................................................................10Le caratteristiche del software......................................................................................................................................................11Caratteristiche di un prodotto Software........................................................................................................................................11I diversi tipi di software.................................................................................................................................................................12Responsabilità (Etica) professionale..............................................................................................................................................12

Che cos’è l’ingegneria del software?...................................................................................................................................................13Perchè l’ingegneria del software è importante?...........................................................................................................................13

Il processo di produzione del Software...............................................................................................................................................15Il Processo per la produzione del software...................................................................................................................................15Modello dei principi dell’ingegneria del Software........................................................................................................................16

Principi fondamentali: il cuore della disciplina........................................................................................................................16Rigorosità e formalità.........................................................................................................................................................16La separazione dei problemi..............................................................................................................................................17Modularità..........................................................................................................................................................................17Astrazione...........................................................................................................................................................................18Previsione dei cambiamenti...............................................................................................................................................19Generalità...........................................................................................................................................................................19Incrementalità....................................................................................................................................................................20

Il ciclo di vita del software...................................................................................................................................................................21Il processo di sviluppo del software..............................................................................................................................................21

Problemi nel processo di sviluppo software............................................................................................................................21Perché avere un modello?.............................................................................................................................................................21Modelli di processo.......................................................................................................................................................................22Modello a cascata (waterfall)........................................................................................................................................................22

Obiettivi del modello a cascata................................................................................................................................................22Fasi del modello a cascata........................................................................................................................................................23


http://qrcode.kaywa.com/

http://www.isisfacchinetti.it/

mailto:[email protected]

http://moodle.isisfacchinetti.it/

http://moodle.isisfacchinetti.it/mod/data/view.php?id=1391

http://isisfacchinetti.gov.it/

http://creativecommons.org/licenses/by-nc-sa/3.0/deed.it

3

1. Studio di fattibilità (cosa)................................................................................................................................................232. Analisi e specifica dei requisiti (capire)..........................................................................................................................233. Progettazione e specifica di progetto (come).................................................................................................................234. Codifica...........................................................................................................................................................................245. Testing.............................................................................................................................................................................246. Istallazione (Messa in esercizio, deployment)................................................................................................................247. Manutenzione................................................................................................................................................................24

Considerazioni sul modello a cascata......................................................................................................................................24La Prototipazione e lo Sviluppo Evolutivo.....................................................................................................................................25Sviluppo incrementale (iterativo)..................................................................................................................................................25Modello a Spirale...........................................................................................................................................................................27Processo agile (usato in open source)...........................................................................................................................................28

Scrum .................................................................................................................................................................................29 Verifica 1 - Lacoop4u...............................................................................................................................................................30 Verifica 2 - Hotmug2.0............................................................................................................................................................31 Verifica 3 - Sweethouse...........................................................................................................................................................31 Verifica 4 - My-s.......................................................................................................................................................................32

Requisiti e specifiche...........................................................................................................................................................................33I requisiti (cosa).............................................................................................................................................................................33Specifiche.......................................................................................................................................................................................35

Stili di specifica.........................................................................................................................................................................36Linguaggi di specifica...............................................................................................................................................................37Esempi: Requisiti – specifiche..................................................................................................................................................39

Un esempio Cambio gomme..............................................................................................................................................39parcheggio controllato.......................................................................................................................................................39

Metodologie per la progettazione di sistemi......................................................................................................................................41Qualità di un progetto..............................................................................................................................................................42La Specifica del Progetto..........................................................................................................................................................42Progettazione top-down e bottom-up.....................................................................................................................................43

Top-down............................................................................................................................................................................43Bottom-up..........................................................................................................................................................................45Top-down vs bottom-up.....................................................................................................................................................45

La Programmazione top-down/bottom-up..............................................................................................................................46Indipendenza Modulare.....................................................................................................................................................47Il principio dell’information hiding.....................................................................................................................................47

Qual è la migliore strategia per lo sviluppo?.................................................................................................................................48Strategia di progetto orientata alle funzioni..................................................................................................................................48

Un esempio di programmazione Top Down (funzionale).......................................................................................................49 Un esempio in Javascript in tempo reale per il controllo dei sensori.....................................................................................51

Strategia di progetto orientata agli oggetti...................................................................................................................................52Differenze e analogie tra approccio funzionale e ad oggetti.........................................................................................................53

Un esempio: le classi in Java....................................................................................................................................................55Il Pattern MVC................................................................................................................................................................................56

ZEND...................................................................................................................................................................................57J2EE.....................................................................................................................................................................................57

L’interfaccia utente..............................................................................................................................................................................58Regole d'oro dell'Interfaccia Utente........................................................................................................................................58

Regola fondamentale (Douglas Adams).............................................................................................................................58Processo di Progettazione dell’Interfaccia...............................................................................................................................58

Come si realizza un progetto software?..............................................................................................................................................60Il team di sviluppo di un progetto software...................................................................................................................................60

Obiettivi....................................................................................................................................................................................60Come?......................................................................................................................................................................................60I Leader....................................................................................................................................................................................61Il team......................................................................................................................................................................................61

Esempi...............................................................................................................................................................................61 Esempio: programma di elaborazione testi......................................................................................................................61

Valutazione del Progetto.....................................................................................................................................................................62Soluzioni per la progettazione.............................................................................................................................................................63

UML...............................................................................................................................................................................................63Tipi di diagrammi UML..................................................................................................................................................................63


4

Diagrammi relativi agli aspetti statici di un sistema.................................................................................................................64Molteplicità delle Associazioni.....................................................................................................................................65

Diagrammi dei Casi d'uso (Use Case Diagram)...................................................................................................................66Diagrammi relativi agli aspetti dinamici di un sistema............................................................................................................67

Diagrammi di Sequenza......................................................................................................................................................68Diagrammi di Stato.............................................................................................................................................................68

......................................................................................................................................................................................69Diagrammi di Attività..........................................................................................................................................................69Diagrammi di Deployment.................................................................................................................................................70

Collaudo del software.........................................................................................................................................................................71Testing e debugging............................................................................................................................................................72

Strategie Problemi e Limitazioni....................................................................................................................................................72I sistemi e il loro controllo...................................................................................................................................................................74

Definizione di sistema....................................................................................................................................................................74Studio dei sistemi e terminologia..................................................................................................................................................75

confine del sistema..................................................................................................................................................................75scatola nera..............................................................................................................................................................................75componenti e collegamenti.....................................................................................................................................................75Comportamento del sistema...................................................................................................................................................76Classificazione dei sistemi........................................................................................................................................................76

Automi a stati finiti - Uno strumento per lo studio di sistemi software:.......................................................................................78Introduzione.............................................................................................................................................................................78L’automa a stati finiti................................................................................................................................................................78

Esempio 1...........................................................................................................................................................................80Esempio 2...........................................................................................................................................................................81Esempio 3...........................................................................................................................................................................81 Esempio 5..........................................................................................................................................................................82Esempio 6 - Regolazione di un orologio digitale................................................................................................................83Esercizio n.0 (parzialmente risolto)....................................................................................................................................83Esercizio n.0.1.....................................................................................................................................................................84Esercizio n.0.2.....................................................................................................................................................................84

Esercizio 12: ASCENSORE A DUE PIANI....................................................................................................................................84Automi riconoscitori................................................................................................................................................................86

Come lavorano gli automi riconoscitori.............................................................................................................................86Esempio 1.1........................................................................................................................................................................87ESEMPI0 1.2 :......................................................................................................................................................................87Esempio 2.1 (II° caso)- Automa che riconosce 1101 sulla linea seriale di collegamento tra due computer......................88Esempio 2.2 riconosce la sequenza xxx e, solo in questo caso, emette 1 in uscita...........................................................88Esempio 2.3 Generatore di parità......................................................................................................................................89Esempio 2.4........................................................................................................................................................................89Esempio 2.5........................................................................................................................................................................90Esempio 2.6 Riconoscere una stringa, sull’alfabeto (a,b), con numero pari di a e di b . Ad esempio aa Si, aabb SI, abb NO, ecc...............................................................................................................................................................................90Esempio 2.8........................................................................................................................................................................91Esempio 2.9........................................................................................................................................................................91............................................................................................................................................................................................92Esempio 2.10......................................................................................................................................................................92Esempio di domande in verifica.........................................................................................................................................92

Il controllo dei sistemi....................................................................................................................................................................94Controllo a Circuito Aperto......................................................................................................................................................94Controllo a Circuito Chiuso con retroazione negativa.............................................................................................................95

Controllo PID..................................................................................................................................................................................97Un caso di studio...........................................................................................................................................................................99

L’analisi del sistema..................................................................................................................................................................99Il modello...............................................................................................................................................................................100Il sistema................................................................................................................................................................................100Il prototipo.............................................................................................................................................................................101Il processo di controllo...........................................................................................................................................................104Comunicazione tra Raspberry e Nucleo.................................................................................................................................105Il sito Web e l’app...................................................................................................................................................................106La conduzione del progetto...................................................................................................................................................106


5

La gestione del tempo............................................................................................................................................................107Esercitazioni......................................................................................................................................................................................108

Progettare con gli EAS..................................................................................................................................................................109DUPLone Assembler....................................................................................................................................................................110Esempi di progetti di ordine generale.........................................................................................................................................110

Progettare una mensola porta-oggetti..................................................................................................................................110Progettare la cuccia del vostro cane......................................................................................................................................110Progettare la potatura di una siepe.......................................................................................................................................111Progettare un giardino...........................................................................................................................................................111Progettare un elicifero...........................................................................................................................................................111Progettare un’applicazione Web per il lavaggio dei denti.....................................................................................................111

BYT Brush Your Teeth........................................................................................................................................................................112Business Plan...............................................................................................................................................................................114


6

Perché siamo qui?“Prof, le assicuro che a casa andava…”-Tipica espressione dello studente quando si prova un progetto in laboratorio - Quando a uno studente si propone un progetto di laboratorio (un programma, un’applicazione software), la prima cosa che deve fare è capire in cosa consiste il PROBLEMA posto. Capire, cioè la questione posta partendo da elementi noti con un ragionamento.

Dall’analisi del problema si arriverà, successivamente, alla PROGRAMMAZIONE che è l’attività che, a partire dal problema, conduce alla creazione del programma che verrà eseguito da un calcolatore.

Purtroppo, spesso, si preferisce partire dal codice, così “non si perde tempo”.In realtà è vero ciò che, ironicamente, afferma la legge di Mayers: “E’ bene trascurare la fase di analisi e progetto, e passare immediatamente all’implementazione così da guadagnare il tempo necessario per rimediare agli errori commessi per aver trascurato la fase di analisi e progetto”.

Capire un problema però è, in molti casi, molto complesso perché si tratta di affrontare elementi nuovi e soprattutto perché ci si deve calare nella mentalità del “cliente”, cioè di colui al quale deve essere fornito il prodotto.

Come avere conoscenza del problema?

Prima di tutto occore sapere COSA si deve fare. Per saperlo occorre analizzare la situazione reale in tutte le sue sfaccettature:

ascoltare il cliente, studiare le problematiche aperte, acquisire competenza sulle tematiche in gioco Infine creare un modello che rappresenti questa realtà.

In secondo luogo (ma solo dopo!), occorre sapere COME si deve fare: progettare una soluzione usando tecniche, metodologie e strumenti adeguati.

Per imparare “COME si deve fare” non basta la “buona volontà”, come spesso si dimostra osservando i risultati di progetti scolastici e non solo!Occorre una disciplina che sia in grado di far emergere con chiarezza i passi da fare per arrivare a un software che, in ultima analisi, sia utile al cliente, senza dimenticare che “il cliente sei proprio TU!” e come tale vuoi un prodotto che soddisfi le tue esigenze, ma che , anche, sia facile da usare, immediato, affidabile, aggiornabile, del giusto prezzo e così via…

Un aiuto ci viene dall’Ingegneria del Software che cerca di mettere ordine il software che è una materia realtivamete “giovane” che risale a 50,60 anni fa. L’ingegneria del software è quel settore dell'informatica che studia sistemi software complessi e che sono il risultato di lavoro di gruppo e hanno una durata di anni e quindi sono soggetti a frequenti modifiche e hanno numerose versioni che si susseguono nel tempo.

Tuttavia i suoi principi possono essere applicati a qualsiasi progetto informatico e sono molto utili a ordinare le informazioni per la realizzazione del progetto software perché (cfr http://home.deib.polimi.it/sanpietr/SE/slides/01.pdf ):

definisce un approccio sistematico allo sviluppo, alla messa in opera e alla manutenzione del software – Definisce metodi tecnici e manageriali per prevedere e tenere sotto controllo i costi per tutta la vita ("lifecycle") dei

prodotti software Come tutte le ingegnerie: – Fornisce una guida per applicare la conoscenza scientifica allo sviluppo di soluzioni


http://home.deib.polimi.it/sanpietr/SE/slides/01.pdf

7

(software) "costeffective" per risolvere problemi pratici a beneficio dell'uomo

NOTA : Processo e prodotto Processo – come avviene lo sviluppo industriale del software Prodotto – che cosa viene realizzato

OBIETTIVO: Studiare i metodi da usare perché il processo porti allo sviluppo di prodotti di qualità

I romani e la costruzione dei ponti

I costruttori dei più grandi ponti dell'antichità furono gli antichi romani. I Romani costruirono ponti ad arco e acquedotti che ancora oggi vengono utilizzati o comunque si trovano in buona condizione strutturale.Un esempio è il Pont du Gard, nel sud della Francia. I Romani utilizzavano anche il cemento.Del resto Pontefice-Pontifex (=pontem facere) significa in latino "costruttore di ponti" .

- Costruzione di un ponte romano (http://www.romanoimpero.com/2010/11/i-ponti-romani.html) - Pont du Gard – ponte romano nel sud

della Francia (https://www.flickr.com/photos/22996675@N07/19631190694/in/dateposted-public/)

Marco Polo descrive un ponte, pietra per pietra.– Ma qual è la pietra che sostiene il ponte? – chiede Kublai Kan.– Il ponte non è sostenuto da questa o quella pietra, – risponde Marco, – ma dalla linea dell’arco che esse formano.Kublai Kan rimane silenzioso, riflettendo. Poi soggiunge:– Perché mi parli delle pietre? È solo dell’arco che m’importa. Polo risponde: – Senza pietre non c’è arco. [Le città invisibili, Italo Calvino]

“Utente - Di lui si dice spesso che non sa quello che vuole. Sarà anche vero, ma una cosa è certa: l'utente sa benissimo quello che non vuole.”


https://www.flickr.com/photos/22996675@N07/19631190694/in/dateposted-public/

http://www.romanoimpero.com/2010/11/i-ponti-romani.html

https://it.wikipedia.org/wiki/Acquedotti

https://it.wikipedia.org/wiki/Antichi_romani

8

-Il Dizionarietto del Diavolo del DP -

altalena come realizzata nella realtà (Ziccardi, ottobre 2016)

Qualche esempio reale“Se i costruttori costruissero come i programmatori programmano, il primo picchio che passa potrebbe distruggere la civiltà.”

- Weinberg (Legge di) -

La produttività dell’industria sw è bassa (http://www.cs.unibo.it/cianca/wwwpages/ids/2.pdf ) Da un’analisi di 13.522 progetti di costruzione sw: – 66% di tutti i progetti falliscono (non hanno risultato utile) 82% dei progetti superano i tempi previsti 48% dei progetti producono sistemi senza le funzioni richieste dai clienti decine di miliardi $ di spreco considerando solo i progetti USA

ERRORI SW: Il 4 giugno 1996 il razzo Ariane 5 è esploso in volo dopo 40 secondi dal decollo

Il razzo trasportava un cluster di satelliti del valore di 500M$ (di allora)Il costo totale di sviluppo del razzo era circa 8 Miliardi di $L'esame dei dati ha indicato in un malfunzionamento software la causa del disastrohttp://sunnyday.mit.edu/accidents/Ariane5accidentreport.html


http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

http://www.cs.unibo.it/cianca/wwwpages/ids/2.pdf

9

Sonda Mariner 1Nel 1962 la sonda Mariner 1 della NASA sbaglia traiettoria subito dopo il lancio e viene distrutta per evitare che ricada alsuolo. L’inci-dente è stato causato da un errore nel software, un singolo carattere sbagliato all’interno del codice sorgente. In particolare, l’erroreconsisteva nell’aver inserito un punto invece di una virgola all’interno di un costrutto do-loop scritto in Fortran, causando un’esecu-zione errata di un algoritmo. (http://www5.in.tum.de/~huckle/bugse.html#mariner )

Radioterapia - Il Therac-25 / 1 Era un dispositivo computerizzato per la radioterapia dei pazienti affetti da cancroTra giugno 1985 e gennaio 1987 sei pazienti sono stati uccisi o feriti seriamente da dosi eccessive di radiazioniRsponsabile era il software di controllo, scritto da un unico programmatore:La sincronizzazione di diversi task era realizzata in modo dilettantesco e improvvisato, e ciò ha causato i problemi Non erano stati effettuati test formali o verifiche, non esisteva alcuna documentazione del software I problemi esistevano nel precedente modello Therac-20, ma moduli di controllo hardware bloccavano la macchinaevitando la somministrazione di dosi eccessive I controlli hardware erano stati eliminati e sostituiti da controlli software, probabilmente per contenere i costi

Missili PatriotNel 1991, durante la prima Guerra del Golfo, il sistema antimissile Patriot intercetta molti missili iracheni ma i fallimenti sono frequen-ti. Le mancate intercettazioni sono dovute ad un errore nel software che introduce un errore che si accumula durante il funzionamentodella batteria di missili. In particolare, l’errore consiste nel fatto che il sistema utilizzava operazioni aritmetiche a virgola fissa a 24 bite frequenti moltiplicazioni per 1/10, valore che in binario è periodico. Il troncamento a 24 bit di questo valore causava un errore che siaccumulava nel tempo. Nonostante il sistema fosse stato progettato per funzionare per un limitato numero di ore, spesso veniva te-nuto acceso per molto più tempo, quindi l’errore accumulato a causa del mancato reset del sistema poteva diventare troppo grande.Questo malfunzionamento ha causato decine di morti tra i soldati americani. (http://www.fas.org/spp/starwars/gao/im92026.htm )

Siti web di riferimento: http://courses.cs.vt.edu/cs3604/lib/Therac_25/Therac_1.html http://it.wikipedia.org/wiki/Therac-25http://www5.in.tum.de/~huckle/bugse.html https://www.researchgate.net/publication/242730674_A_CACCIA_DEGLI_ERRORI_DEL_SOFTWARE

NOTA Tipi di errori nel software. Secondo la terminologia definita dall’IEEE [14] esistono diversi tipi di errori nel software:

• Error: è un errore umano nel processo di interpre-tazione delle specifiche, nel risolvere un proble-ma o nell’usare un metodo.• Failure: è un comportamento del software nonprevisto dalle specifiche.• Fault: è un difetto del codice sorgente (detto anche bug)

EsercizioTrovare 3 esempi di errori software che hanno causato incidenti o problemi


https://www.researchgate.net/publication/242730674_A_CACCIA_DEGLI_ERRORI_DEL_SOFTWARE

http://www5.in.tum.de/~huckle/bugse.html

http://it.wikipedia.org/wiki/Therac-25

http://courses.cs.vt.edu/cs3604/lib/Therac_25/Therac_1.html

http://www.fas.org/spp/starwars/gao/im92026.htm

http://www5.in.tum.de/~huckle/bugse.html#mariner

10

Cos'è il Software?Non solo programmi, ma l’insieme degli ‘artifatti’ che lo compongono, prodotti durante il suo sviluppo e la documentazione associata: manuale di configurazione, manuale utente...

Tipi di Software: Generici. Sviluppati per essere venduti ad una vasta gamma di utenti. Contribuiscono alla maggior spesa di software Personalizzati. Sviluppati per un utente specifico in base alle sue esigenze. Richiedono il maggiore sforzo per lo sviluppo

Un sistema software, essendo rivolto ad altri utenti, dovrà essere usabile, portabile, affidabile, etc…

La definizione IEEE (Institute of Electrical and Electronic Engineers)“insieme di programmi, procedure, regole, e ogni altra documentazione relativa al funzionamento di un sistema di elaborazione dati”

Il processo software: Problemi della produzione del software. Cicli di vita del software.

Analisi e progettazione: Aspetti generali dell’analisi e della progettazione. Analisi e progettazione orientata agli oggetti. UML come linguaggio di analisi e progettazione. Pattern architetturali e di progettazione. Progettazione dell’interfaccia. Documentazione. Testing, validazione e debugging: Obiettivi e pianificazione del testing. Progettazione e valutazione dei casi di test.

Debugging. Manutenzione: tipi e processi di manutenzione software. Gestione della configurazione.

Costi nel processo di produzione del Software

Le economie di tutti i paesi sviluppati dipendono dal software, e la maggior parte dei sistemi sono controllati da software. Gli investimenti per il software rappresentano una parte significativa del PIL di tutte le nazioni industrializzate.Il software costa più dell'hardware. Il mantenimento di un software complesso costa più dello sviluppo dello stesso, specialmente per sistemi con lunga vita. É più costoso manutenere il software piuttosto che svilupparlo, soprattutto per sistemi di vecchia data (i cosiddetti sistemi legacy).

L’Ingegneria del software ha come obiettivo riuscire a sviluppare software in maniera efficace e con costi contenuti (cost-effective).

Circa il 60% dei costi è legato allo sviluppo, il 40% sono costi per la verifica e validazione (testing). I sistemi software sono intangibili pertanto è necessario documentare e tenere traccia di ciò che si sta facendo.

◦ Ogni fase del processo di produzione deve sfornare qualche documento ◦ Tali documenti rendono visibile il processo di produzione del software. ◦ I manager si basano sui documenti per prendere le decisioni ◦ I documenti potrebbero non essere pronti quando richiesti, perché i tempi di sviluppo possono non

coincidere con quelli in cui si devono prendere le decisioni. ◦ La necessità di approvare documenti rallenta il processo di sviluppo. ◦ Il tempo necessario per revisionare ed approvare i documenti può essere significativo


11

Le caratteristiche del softwareIl software si sviluppa o si struttura, non si fabbrica nel senso tradizionale. Lo sviluppo del software e la progettazione dell'hardware sono attività profondamente diverse. Il software non si “consuma” come avviene per l’hardwareMentre l'industria si dirige sempre più verso un assemblaggio a componenti, la maggior parte del software viene realizzato in modo specifico

Caratteristiche di un prodotto Software Mantenibilità Evolvere in rapporto alla modifica di requisiti Affidabilità Ci si deve poter fidare del prodotto Software; Correttezza, Robustezza, Verificabilità, Sicurezza – Innoquità Efficienza Non deve sprecare risorse (memoria, tempo,...) Usabilità Deve avere interfaccia e documentazione appropriate


12

I diversi tipi di software Software di sistema

o Collezione di programmi al servizio di altri programmi (compilatori, editor, strumenti per la gestione di file...) Software real-time

o E' il software che sorveglia, analizza, controlla eventi esterni mentre avvengono Software gestionale

o Elaborazione di dati aziendali Software scientifico e per l'ingegneria

o Algoritmi di calcolo intensivo (astronomia, vulcanologia, biologia molecolare, terremoti...) Software embedded Risiede generalmente in memorie per sola lettura e ha lo scopo di controllare prodotti e sistemi di

consumo o Iindustriali Software per i personal computer

o Elaborazione testi, fogli elettronici, grafica, programmi multimediali... Software basato sul Web

o CGI, PHP, .Net, Java... Software per l'intelligenza artificiale, machine learning

o Algoritmi non numerici (euristici) per la risoluzione di problemi complessi

Esercizio1Elencare 2 applicazioni software per ogni tipologia

Esercizio2Machine learning: principi e finalità

Responsabilità (Etica) professionaleNon limitarsi agli aspetti tecnici, ma guardare anche ai risvolti etici, sociali e alle responsabilità professionali: essere onesti non è solo rispettare le leggi:

- Confidenzialità - Competenza- Diritti di proprietà intellettuale - Uso inappropriato dei computer (ACM/IEEE, Code of Ethics” )

“Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC - Software engineers shall act consistently with the public interest.2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.

8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.”


13

Che cos’è l’ingegneria del software?

L'Ingegneria del Software è un insieme di teorie, metodi e strumenti per sviluppare software di qualità in maniera professionalein altre parole:una disciplina ingegneristica che si occupa di tutti gli aspetti relativi alla produzione del software e propone un approccio sistematico e organizzato per il loro lavoro, usando strumenti e tecniche appropriate.

Una domanda fondamentale Che cosa significa scrivere del buon software? Risposta del programmatore C: “Scrivere del buon software significa ottimizzare ogni istruzione, in modo da ottenere il codice più compatto ed efficiente possibile” Risposta del programmatore Visual Basic: “Scrivere del buon software significa fornire le funzionalità richieste dall’utente nel minor tempo possibile e col minor costo possibile, indipendentemente da come si arriva al risultato” Risposta dell’ingegnere del software “Scrivere del buon software significa

Trovare il miglior equilibrio fra diversi fattori: ◦ La soddisfazione dell’utente ◦ La facilità di estensione dell’applicazione ◦ La comprensibilità delle soluzioni adottate

Adottare tecniche adeguate a gestire la crescente complessità delle applicazioni Ingegneria del Software. Utilizzare al meglio l’investimento, spesso ingente, necessario per produrre un’applicazione, garantendo in particolare:

◦ Il maggior tempo di vita possibile ◦ Il riutilizzo in altri progetti di parte del codice prodotto Ingegneria del Softwar◦ Affrontare in modo sistematico e misurabile: il progetto la realizzazione l’utilizzo la manutenzione dei prodotti

software ◦ Studiare le strategie per realizzare il punto precedente Ingegneria del Software

Perchè l’ingegneria del software è importante?“Io sviluppo, Tu installi, Egli prega.” -Anonimo -

Il Software è : intangibile Difficile comprenderne la complessità, la qualità, lo sforzo necessario per lo sviluppo Il Software è facile da riprodurre I Costi maggiori sono nel processo di progettazione e sviluppo, diversamente da altri prodotti industriali L’industria del software richiede un grosso impegno intellettivo É difficile da automatizzare


14

L’ingegneria del software : punta a produrre software affidabile, sicuro, usabile e manutenibile. diversamente dalla programmazione, non si preoccupa solo della funzionalità o di particolari caratteristiche del

sistema. è particolarmente importante per sistemi da cui dipendono persone e processi che vengono usati per molti anni.

software vs Ingegneria del software

L’informatica si occupa delle teorie e dei metodi allabase dei sistemi software ed informatici;

l’ingegneria del software si occupa degli aspetti praticirelativi alla produzione del software.

Anche se le teorie ed i principi informatici sono fondamentali, spesso vengono trascurati dagli ingegneri del software per questioni di praticità (diversamente da quanto accade in altre branche ingegneristiche).

I miti del …

management cliente programmatore

Abbiamo standard e procedureda seguire nello sviluppo. Non ciserve altro”

Abbiamo i più moderni sistemidi sviluppo.

Acquistiamo i computer semprepiù recenti”

Sviluppare non è una attivitàfacilmente automatizzabile.

Se siamo in ritardo, possiamorecuperare aumentando ilnumero di programmatori

“Adding manpower to a lateproject makes it later” - FredBrooks

“se una donna partorisce in 9mesi, due donne lo fanno in 4 mesie mezzo” - paradosso della partoriente -

“Un'affermazione generica dicosa deve fare un programma èsufficiente per iniziare a scriverecodice”

I requisiti mutano di continuo,ma i cambiamenti si gestisconofacilmente grazie alla flessibilitàdel software”

Il solo prodotto di un progettoconcluso è il programmafunzionante”

L'ingegneria del software ci faràscrivere un'inutile e voluminosadocumentazione cheinevitabilmente rallenterà lacose”


15

Il processo di produzione del Software

I tools per la produzione del software: …..

Il Processo per la produzione del software“Un processo software – o processo per lo sviluppo del software – è un insieme strutturato di attività che porta alla creazione di un prodotto software.

Un processo definisce chi fa che cosa, quando e come per raggiungere un certo obiettivo. Precisamente:

Attività di analisi Attività di progettazione Attività di codifica Attività di verifica e convalida (testing) Attività di tipo gestionale

◦ Stime dei costi (e dei tempi) ◦ Pianificazione dei progetti (delle persone, risorse,..) ◦ Analisi dei rischi ◦ Gestione della qualità

Esistono numerosi processi software, organizzati attorno ad attività comuni. Il loro scopo è soddisfare le aspettative dei clienti, fornendo prodotti di qualità, nei tempi e nel budget previsto, rendendo i prodotti remunerativi e i processi affidabili, prevedibili ed efficienti.

Tutti i processi software sono basati su un certo numero di attività fondamentali comuni: allora, perché ci sono tanti approcci diversi che descrivono il processo? In che cosa si differenziano tra loro? Processi diversi fanno riferimento a scelte differenti per


16

alcune funzioni primarie del processo: come viene determinato l’ordine delle attività? Per quanto tempo continueremo a fare questa cosa? Che cosa faremo dopo?

Per questo ci serviremo di “modelli”. Un modello di processo software è una rappresentazione astratta di un processo software. Ogni modello rappresenta un processo da un particolare punto di vista fornendo però solo informazioni parziali a riguardo.”(http://www.dia.uniroma3.it/~cabibbo/asw/pdf/asw210-processi-software.pdf)

Modello dei principi dell’ingegneria del Software


I campi dell’ingegneria del software (Ogni strato si basa su quello immediatamente più interno ):1. Principi: il cuore della disciplina , sono le linee guida , astrarre dai dettagli. Dicono il MODO con cui va fatta una certa

cosa, però NON dicono come. 2. Metodi e Tecniche: implementano i principi, applicazione dei principi al problema, strumenti per automatizzare il

processo. Soluzioni basate sui principi: COME va fatta una certa cosa. 3. Metodologie: come integrare i principi e le tecniche; quali tecniche usare in un certo contesto, quando applicarle e

come usare i metodi. Come mettere insieme le tecniche.4. Strumenti sono i tools che applichiamo alle metodologie

I Principi fondamentali che si applicano sia al processo che al prodotto. Si applicano attraverso metodi etecniche. Metodi e tecniche si possono comporre in metodologie. L’applicazione delle metodologie puòavvalersi di (o essere imposta da) strumenti.

Principi fondamentali: il cuore della disciplina

I principi fondamentali dell’ingegneria del software, cioè le linee guida per la sua progettazione, comprendono: Rigorosità e formalità La separazione dei problemi Modularità Astrazione Previsione (Anticipazione) dei cambiamenti Generalità/Riusabilità Incrementalità

Rigorosità e formalità L’ingegneria del software è un’attività creativa. Deve però essere praticata in modo sistematico. Il rigore aumenta la nostrafiducia nei prodotti. La formalità (definizione matematica dei concetti usati) è il rigore al massimo grado.L’uomo è sempre l’elemento essenziale ma si migliora, si amplifica con dei complementi alla CREATIVITA’ umana, ad esempio con



http://www.dia.uniroma3.it/~cabibbo/asw/pdf/asw210-processi-software.pdf

17

il rigore e la formalità: trovare la soluzione espressa in modo formale per comprendere i risultati e condividerli (ad es. la matematica: prova formale di correttezza di un teorema). La formalità (che ha un costo!) facilita le procedure automatiche di generazione e verifica.La rigorositàPermette di rendere la creatività condivisibile e capibile.

Ad esempio la descrizione formale e la prova formale di un protocollo di comunicazione. Ad esempio documentazione precisa, con forme definite per semplificare la comunicazione: capitoli, regole, rigore.

Esiste anche una documentazione informale o formale, cioè forme definite e precise per semplificare la documentazione: ci sono moduli, capitoli, regole specifiche

Esempi: - prova formale (matematica) di correttezza di un programma, generazione sistematica dei dati di test - (processo) una documentazione rigorosa del processo facilita la gestione dei progetti e il controllo dei tempi di produzione

La separazione dei problemi E’ fondamentale perché, oltre un certo livello di complessità, non siamo più in grado di vedere TUTTI i dettagli (ad es. Sistema Operativo). Affrontare la complessità di un problema considerandone separatamente gli aspetti. Quasi sempre gli aspetti di un problema come la produzione di un software sono correlati e a volte in contrasto. Tuttavia, nella pratica, la separazione degli interessi è necessaria (anche per suddividere il lavoro fra persone). E’ importante capire che noi, esser umani, NON SIAMO IN GRADO DI PRENDERE IN CONSIDERAZIONE TUTTI I DETTAGLI: è un limite intrinseco alla mente umana.(ad es. Ssitema Operativo).Ad es. Chi conosce tutti i dettagli di un’automobile? NESSUNO!!! Motoristi, meccanici,… divido la macchina in…Ad es. il software lo divido in basi dati, funzioni, presentazione.

Come si fa allora? Sottoproblemi , “Divide et Impera”.

- divide et impera («dividi e conquista»), significa che la divisione giova a chi vuol dominare.Ai tempi dei romani tale strategia era un mezzo adoperato per governare il territorio italiano o estero, evitando che le singole popolazioni si coalizzassero in rivolte e sommosse contro Roma. Un tipico esempio fu l'invasione della Macedonia e la sconfitta del re Perseo di Macedonia nella battaglia di Pidna (168 a.C.), dopo la quale la Macedonia fu divisa in quattro repubbliche dipendenti da Roma, cui furono pesantemente limitati i rapporti reciproci nonché quelli con gli altri stati ellenici. (Wikipedia). In informatica la locuzione indica una metodologia per risolvere problemi: il problema viene diviso in sottoproblemi più semplici e si continua fino a ottenere problemi facilmente risolvibili; combinando le soluzioni ottenute si risolve il problema originario.(http://www.treccani.it)

ModularitàModularità = Dividere il sistema in moduli che hanno alta coesione e basso accoppiamento (pochi link (ricorda: legami forti e deboli!!)). Riusati e integrati. Divisione Processo in fasi, fasi in attività, attività in sottoattività…Favorisce la comprensibilità e la manutenibilità . Identificare moduli che possono essere riusati. Permette di scomporre un sistema in parti più semplici e comporre un sistema a partire da parti più semplici. Permette di comprendere un sistema come insieme di parti interagenti.Es il test in varie fasi per collaudare il sistema per gestire la complessità.


https://it.wikipedia.org/wiki/Regno_cliente_(storia_romana)

https://it.wikipedia.org/wiki/168_a.C.

https://it.wikipedia.org/wiki/Battaglia_di_Pidna

https://it.wikipedia.org/wiki/Perseo_di_Macedonia

https://it.wikipedia.org/wiki/Perseo_di_Macedonia

https://it.wikipedia.org/wiki/Macedonia_(provincia_romana)

https://it.wikipedia.org/wiki/Storia_romana

18

04-principi.pdf - http://www.unife.it/ing/lm.infoauto/ing-sw-ii/diapositive-del-corso/

Alta coesione dei moduli. Gli elementi di un modulo sono raggruppati per un motivo logico es.: funzioni raggruppate come metodi di una classe se condividono lo stato

Debole accoppiamento fra moduli : due moduli hanno poche dipendenze reciproche. IN questo modo è più facile considerarli separatamente e sostituirne uno è meno costoso

Attenzione, però, i link DEVONO ESSERCI, se no si torna a due diversi sistemi indipendenti! Moduli diversi, disaccoppiati sono due sistemi completamente diversi.

AstrazioneIgnorare i dettagli. Ragionare sui MODELLI. L’astrazione produce modelli.

Esempi di modelli:

La specifica (formale o informale) di un software è un modello della sua implementazione. Ragionando sulla specifica si possono ignorare i dettagli implementativi

Ex circuiti elettrico descritti con equazioni differenziali che comprende solo alcuni elementi del circuito, astrazione del circuito fisico: non è il circuito ma mi permettono di ragionare meglio

Ex F=m*a Ex. S.O. modello a cipolla. Ragioniamo su un aspetto del modello ex. Memroia o kenel Ex. Livelli OSI Ex il codice dal modello senza linguaggi di programmazione : assembly -> Java-> modello astratto. Qui perdo una

serie di elementi ma so cosa Ex. Ingegneria del software basata su modelli , come si fa nell’hardware. Passi meccanici che non richiedono la

creatività Ex. Compilatori, oggetti, astrazione dai linguaggi di programmazione con la creazione di un modello Ex: la semantica dei linguaggi di programmazione astrae dall’hardware sottostante

Codice modello con tutti i dettagli (è già un’astrazione del codicebinario)

modello a stati: ignora dettagli che qui noninteressano


http://www.unife.it/ing/lm.infoauto/ing-sw-ii/diapositive-del-corso/

19

public void run()

{

System.out.println("[SERVER] In ascolto");

{

// Inizializzazione degli stream

BufferedInputStream bin = new BufferedInputStream(client.getInputStream());

in = new DataInputStream(bin);

BufferedOutputStream bout = new BufferedOutputStream(client.getOutputStream());

out = new DataOutputStream(bout);

// Ricezione del messaggio proveniente dal client

String message = in.readUTF();

Ovviamente è sempre l’uomo deve capire cosa astrarre cosa no.Esempio IL COMPILATORE. La compilazione si può suddividere in alcune fasi:

Analisi lessicale Analisi sintattica (parsing) Generazione del codice

La suddivisione in fasi si può riflettere nella suddivisione del sistema in moduli

Sviluppo di un compilatore per un sottoinsieme del linguaggio, poi aggiunta progressiva di tutte le caratteristiche Concentrarsi successivamente su correttezza, diagnostica, ottimizzazione. Fornire via via un insieme sempre più ampio di librerie

Previsione dei cambiamentiIl software evolve: verificare se il sw potrà essere diverso in futuro o usato in maniere diverse. Metodologie e tecniche per verificare se il sw dovrà cambiare.

Ad ex. Versione e modifiche e compatibilità tra le versioni

GeneralitàRisolvere il problema generale. Riusabilità.

Ex. Funzione di ordinamento per campi diversi, crescente, decrescente. Più la soluzione è generale più è usabile. Tecno2 - L’ingegneria del software – paolo macchi - ISIS Facchinetti rel. 19.02.05

20

Ma .. ovviamente il costo è funzione della generalità e della riusabilità. Quindi qual è il livello a cui fermarsi.

IncrementalitàProcedere a passi successivi. In molti casi può essere utile portare avanti un processo come sequenza di passi successivi verso il prodotto finale. Permette di ricevere feedback sui prodotti intermedi L’incrementalità è strettamente correlata all’evolvibilità. Ad ex. Sviluppo a modelli per prototipi incrementali. Sviluppo a passi successivi, prototipi incrementali che posso verificare di passo in passo e togliere l’ansia al cliente con convalide successive. C’è un costo ovviamente e il pericolo di troppi prototipi. Cioè, consegnare una versione del sistema con funzionalità ridotte, per ricevere un primo feedback implementare prima le funzionalità, poi prendere in considerazione le prestazioni e produrre una serie di prototipi mentre aumenta la comprensione deirequisiti.

NOTA: I principi ci devono guidare ma non c’è la soluzione universale di tutti i problemi però ci aiutano a capire cosa è meglio e cosa è peggio.Avere pero’ un principio è importante!

Esercizio : come vengono implementati questi punti ad esempio nella costruzione di una automobile? Dov’è la modularità, incrementalità, astrazione?


21

Il ciclo di vita del software

Il processo di sviluppo del software

Il processo di produzione software è un insieme di attività il cui fine è lo sviluppo oppure la modifica di un prodotto software Attività generiche in tutti i processi di produzione del software:

Specifica – cosa deve fare il sistema e quali sono i vincoli per la progettazione. Accordo fra il produttore e il consumatore di un servizio

Sviluppo – produzione del sistema software Validazione – verifica che il software faccia ciò che il cliente richiede Evoluzione – modificare il software in base alla modifica delle esigenze

Problemi nel processo di sviluppo software

Specifiche incomplete/incoerenti Mancanza di distinzione tra specifica, progettazione e implementazione Assenza di un sistema di validazione

Il software non si consuma: la manutenzione non significa riparare alcune componenti rotte, ma modificare il prodotto rispetto anuove esigenzeI sistemi software sono intangibili. Pertanto è necessario documentare e tenere traccia di ciò che si sta facendo

Perché avere un modello?Il ciclo di vita del software definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suorilascio, alla sua successiva evoluzione, fino al suo ritiro. Definisce dunque il processo attraverso cui il software evolve si parla disoftware lifecycle o software Process.

Un modello permette l’esistenza di un processo pianificato e lo sviluppo NON avviene in maniera spontaneistica (caotica?), e cio`implica:

controllo dei tempi controllo dei costi qualita` dei prodotti

Qualunque "industria" ha un modello per la produzione dei beni. Il modello consente: di pianificare le attivita` e le risorse necessarie di prevedere e controllare i costi del processo e la qualita` dei prodotti

L’ingegneria del software definisce metodi e procedure per lo sviluppo del software, utili ad ottenere sistemi di grandi dimensioni, di alta qualità, a basso costo, ed in breve tempo. Per conseguire tali obiettivi occorre puntare sulla qualità del processo di sviluppo del software il software come altre industrie manifatturiere.


22

Modelli di processoProcessi di produzione del Software: insieme coerente di attività per la specifica, il progetto, l'implementazione, la verifica di sistemi softwareUn modello di processo è una rappresentazione astratta di un processo. Descrive un processo da una particolare prospettiva.Ci sono modelli di processo generici:

A cascata (il primo che risale agli anni ’60) Fasi distinte di specifica e sviluppo

Modello evolutivo Specifica e sviluppo interagiscono (prototipi)

Modello trasformazionale Un sistema matematico è trasformato formalmente in una implementazione

Sviluppo basato sul riutilizzo Il sistema è ottenuto combinando componenti esistenti

Noi ci soffermeremo sul Modello a Cascata e sul Modello Evolutivo. Il primo perché è storicamente il più rilevante e perché da esso si evolvono i successivi. Il secondo perché è quello attualmente più usato.

Modello a cascata (waterfall)È il modello più tradizionale di sviluppo del Software, che prevede una sequenza di fasi, ciascuna delle quali produce un ben preciso output che viene utilizzato come input per la fase successiva (da cui la metafora della cascata). Pur essendo stato soggetto a profonde critiche revisioni negli ultimi decenni (il modello è degli anni ’60 del secolo scorso) , rimane il metodo di riferimento universalmente accettato, rispetto al quale tutti gli altri risultano delle varianti piuttosto che delle vere alternative.

Attività che vengono una dopo l’altra; prima completata, seconda completata…E’ un modello per sua natura DOCUMENTALE: fase, documento, fase, documento…

Obiettivi del modello a cascata

Cercare un metodo sistematico che consenta di identificare fasi e attività attraverso cui procedere standardizzare gli output di ciscuna fase (semilavorati—"artifacts") forzare un procedimento lineare di passaggio tra una fase e la successiva, a completamento avvenuto della fase nessun ritorno all'indietro, considerato dannoso perché impedisce una buona pianificazione e controllo

In definitiva: la produzione di software come catena di montaggio!


23

Fasi del modello a cascata

1. Studio di fattibilità (cosa)Definizione di che COSA deve essere fatto e non come deve essere fatto!

stabilire se lo sviluppo debba essere avviato (COSTI/BENEFICI) quali le alternative possibili e le scelte più ragionevoli. stima delle risorse finanziarie e umane necessarie, per ciascuna possibilie soluzione. redazione di un un Documento di Fattibilità.

In pratica: siamo in grado? Ne vale la pena? Se sì, produciamo un Documento.

2. Analisi e specifica dei requisiti (capire)CAPIRE il problema e formularlo correttamente per chi deve risolverlo. Si va dal cliente e si cerca di capire il problema. NB il “cliente” può essere il “mercato” e non necessariamente in carne e ossa.

Definizione del problema, tramite ‘interviste’ con il commitente, di funzioni, vincoli, prestazioni, interfacce e di qualsiasi altra caratteristica che il sistema dovrà soddisfare.

redazione di un Documento di Specifica dei Requisiti Software, che sia completo, preciso, consistente, non ambiguo, comprensibile in maniera adeguata sia al committente che allo sviluppatore. Si distingue tra:

o Specifica dei requisiti: accordo fra sviluppatore e utente finale . La Specifica dei requisiti,come accordo fra sviluppatore e utente finale, è una fase difficile e critica (una specifica sbagliata porta necessariamente al fallimento del progetto).

o Specifica di un progetto: accordo fra progettista e implementatori o Specifica di un modulo: accordo fra i programmatori che lo useranno e quelli che lo implementano

predisposizione di un piano di test e della versione o del manuale utente Si produce un documento (una specifica dei requisiti) da passare alla fase di progettazione.

3. Progettazione e specifica di progetto (come)Si cerca di trovare una SOLUZIONE al problema che si era individuato e capito nelle fasi precedenti.Si parte dal Documento di Specifica e si cerca di capire COME realizzarlo

definizione dell’architettura del sistema: definizione macroscopica dei componenti del sistema e delle relazioni tra questi (progetto di alto livello – HLD) e, via via, definiremo i dettagli: partiamo dallo stile architettonico (proprio come nella costruzione di una casa) per arrivare i componenti di dettaglio e le loro relazioni

definizione della struttura interna di ciascun componente (progetto di dettaglio – LLD). definizione della struttura dei dati e delle interfacce utente. redazione di un documento di Specifica di Progetto.


24

Si opera come nella costruzione di un edificio: qual è lo stile (romanico, neoclassico, post-moderno..), in base a questo quali colonne mettere, come dipingerlo etc. Dividere il lavoro a gruppi: gruppo dell’edificio di base, gruppo delle colonne, infissi, tetto…

Ad esempio se l’analisi ci ha fornito un documento per la progettazione di una applicazione Web, la progettazione dovrà dividere il progetto nella parte relativa alla logica dei dati, all’interfaccia e presentazione verso l’uomo, alla sicurezza etc.Cosi’ si Dividono le Responsabilità: gruppi di lavoro relativi alle fasi stabilite (ad esempio un gruppo per la logica dei dati, un altro per l’interfaccia, un altro per la sicurezza etc.).

4. CodificaImplementazione dei vari componenti definiti nel Progetto.Traduciamo i componenti individuati nel progetto in codice (in realtà non si tratta solo di”tradurre” ma occore una buone dose diintuizione e creatività)NB qui il modello dimostra tutta la sua età, perché si è ignorato, fino a qui, il controllo della qualità che verrà attuata solo alla fine del lavoro.

5. TestingDefinizione ed esecuzione di “casi di prova” sia per i singoli componenti (Test delle singole unità) che per l’intero sistema con l’intento di rilevare malfunzionamenti.Si procede poi con i Test di integrazione delle varie componenti

6. Istallazione (Messa in esercizio, deployment)Insieme di tutte le operazioni necessarie per il rilascio, l’installazione sul campo e rendere operativo il sistema realizzato presso ilcommittente.

Test di sistema

7. ManutenzioneProcesso di modifica di un sistema o di un componente software dopo il suo rilascio al fine di eliminare anomalie, migliorare le prestazioni o altri attributi di qualità, o adattarlo a mutamenti dell’ambiente operativo e/o del dominio applicativo.

Considerazioni sul modello a cascata

Con il modello di sviluppo a cascata, la produzione del Software è stata sottoposta per la prima volta ad una disciplina ben definita, assumendo i connotati del processo industriale. La suddivisione del processo in fasi correlate ha consentito di assegnare a ciascuna fase compiti specifici, rendendo più ordinato l'indirizzamento delle varie problematiche. Uno dei limiti maggiori di questo approccio è che il livello di parallelizzazione delle attività è piuttosto basso e questo provoca, specialmente nei progetti di grandi dimensioni, un allungamento dei tempi che può risultare inaccettabile per le esigenze del business. Vantaggi e limitazioni del modello a cascata:

Vantaggi Svantaggi

la fasi da seguire sono ben definite; gli output di ciascuna fase precisamente individuati.

basato sul ben consolidato modello ingegneristico per la risoluzione dei problemi

È semplice da spiegare e da capire: prima si raccolgono tutti i requisiti, poi si fa tutta l'analisi, poi tutto il design, poi tutta la codifica, ...

È semplicissimo organizzare il piano di progetto (non ci sono dubbi sulla sequenza delle fasi).

Si adatta bene a logiche organizzative e politiche del personale

le fasi avanzano in ordine tipicamente sequenziale . Ilprocesso è poco efficace rispetto alla evolvibilità. Va benese NON ci saranno cambiamenti futuri (ammesso siapossibile). Quindi…

Difficile operare cambiamenti una volta che il processo èin corso. Pertanto è difficile soddisfare cambiamenti neirequisiti da parte del committente (grosso limite!)

Il partizionamento in fasi può apparire arbitrario oartificioso

Difficoltà a stimare in modo accurato i costi e le risorsenecessarie nella fase iniziale del progetto, quando ancoramancano sufficienti elementi di dettaglio ma è giànecessario definire budget e piano di lavoro.


25

modello adeguato quando i requisiti sono ben compresi e non soggetti a modifiche

Necessità di aderire a precisi standard nella produzionedei documenti di progetto, con il rischio di introdurre unaeccessiva burocratizzazione delle attività.

Il documento che specifica i requisiti non sempre soddisfale effettive esigenze degli utenti perché spesso gli utentistessi non sono in grado di conoscere e quindi didescrivere con efficacia tutti i requisiti dell'applicazione.Considerando che questo documento vincola il prodottoda sviluppare, la sua rigidità sin all'inizio del processorappresenta un limite piuttosto significativo per la qualitàdel prodotto finale.

La Prototipazione e lo Sviluppo EvolutivoSpesso i requisiti del modello a cascata non sono abbastanza chiari. Il cliente stabilisce gli scopi generali del sistema software, ma non ne chiarisce subito i requisiti in modo dettagliato. I programmatori sono incerti sul significato dei requisiti, o su come strutturare l'interfaccia o gli algoritmi. Inoltre i requisiti cambiano nel tempo e non posso prevederli a priori. Ad esempio

faccio un software per la vendita che calcola l’IVA che potrà cambiare. Cambio del sistema operativo e delle sue versioni. Non ho la possibilità di sapere se Microsoft cambierà le sue

versioni e quando. Ambiente software classico spostato in ambiente client-server su Web.

In tali casi viene in aiuto una metodologia di sviluppo basata su PROTOTIPI (paradigma prototipale) orientata ai cambiamentiI prototipi approssimano il sistema definitivo in modo incrementale. Talvolta si usano prototipi usa e getta usati solo per provare un concetto: si prova e poi si butta via (si è capaci di “buttare”?).Due tipi di cambiamento del processo:

Cambiamenti nel corso dello sviluppo Cambiamenti in essere (una volta sviluppato il prodotto)

La prototipazione rapida richiede un ciclo di vita flessibile e iterativo. Richiede accurata documentazione dei passi intermedi e delle loro relazioni per evitare di perdere il controllo .Il modello è legato a uno sviluppo evolutivo e a una costruzione incrementale del sistema che produce feedback e concetti nuovi.

Sviluppo incrementale (iterativo)

Un’idea fondamentale dello sviluppo incrementale (o iterativo) è quella che alcune parti di alcune attività vengono rimandate


26

(ad es., la comprensione di certi requisiti) anticipando al loro posto altre attività (ad es., l’implementazione di altri requisiti) in modo da perseguire alcuni obiettivi ( ad es., produrre il prima possibile un insieme utile di funzionalità, affrontare il prima possibile).Lo stile iteartivo suddivide il progetto in sottoinsiemi con funzionalità diverse. Ad esempio il corso di Teconologia viene suddiviso in due quadrimestri. Nella prima parte si svolge un intero ciclo con un test finale (i risultati sono codificati nella pagella). Il ciclo è, a sua volta diviso, in periodi di circa un mese che comprendono una attività didattica definita. Ogni periodo si conclude con una verifica. L’intero anno scolastico copre tutti i requisiti ma essi sono ripartiti in cicli ciascuno delle quali adotta tutte le fasi : spiegazione, studio ed elaborazione personale, verifica. Ogni ciclo, in se stesso è completo e si ripete circolarmente. Se avessimo adottato un modello a cascata avremmo avuto una situazione differente: ad esmpio il primo quadrimestre sarebbe stato dedicato alle spigazioni, il secondo allo studio e alle prove pratiche e, infine avremmo avuto un test finale.Naturalmente questa è una descrizione semplificata ma mostra le differenze tra i due approcci.Nella pratica, spesso, i due approcci non sono così rigidi e c’è una “contaminazione” tra i due. Se ci riferiamo all’esempio precedente a cascata, potrebbe capitare che durante il secondo quadrimestre siano richieste ulterirori spiegazioni e approfondimenti. Questo è abbastanza ovvio. Tuttavia occorre, nel modello a cascata, cercare di rendere minimi questi ritorni e rivistazioni del progetto che dovrebbero essere delle eccezioni e non la regola.

Nel caso del software, ogni ciclo deve essere completo: analisi, progettazione, codifica e testing. Se il progetto è diviso in 2 iterazioni, alla fine della prima avreste avreste ottenuto la metà delle funzionalità richieste.Alla fine di ogni iterazione, non è detto che si debba necessariamente rilasciare un prodotto (così come un o studente che è sufficiente nel primo quadrimestre non può passare alla classe successiva!), anche se spesso si decide di rilasciare una più releasein modo da avere un riscontro dagli utenti.

Problemi Mancanza di visibilità (quando produrre i documenti?) I sistemi prodotti sono spesso poco strutturati Competenze particolari sono spesso richieste (es. in linguaggi per la prototipazione rapida) Occorre resistere alla tentazione di trasformare il prototipo in un prodotto da porre in produzione Al cliente il prototipo potrebbe apparire funzionante, ma in realtà potrebbe avere tali e tanti problemi da renderlo di

fatto inutilizzabile in condizioni reali. Quindi il sistema va rifatto

Ci sono molti modelli simili che ricalcano gli stessi obiettivi:

Nella figura sottostante è mostrato il modello incrementale perseguito da Microsoft:

Esempio di modello incrementale . Modello usato in Microsoft: Sviluppo 4-8 settimane, stabilizzazione 2-4 settimane

Nella figura sottostante è mostrato il modello incrementale in cui le fasi sono parallelizzate e sono parzialmente sovrapposte:


27

Un esempio di sviluppo incrementale

Modello by CISCO “The five steps are cyclical, which means that they can be repeated as many times as needed to make improvements in the design process. “:

Modello a Spirale Il processo di sviluppo è rappresentato come una spirale, piuttosto che come una sequenza. Ogni ciclo nella spirale è una fase del processo Al termine di ogni “giro” il risultato può essere un progetto, un prototipo, un sistema funzionante o un prodotto software completo Non ci sono fasi predefinite. Il management del progetto deve decidere come strutturarlo in fasi


28

La spirale è divisa a “spicchi:” Comunicazione con il Cliente. Specificare gli obiettivi e i vincoli di quella fase, identificare i rischi ed eventualmente

proporre delle strategie alternative Pianificazione. Attività rivolte a definire scadenze e risorse Analisi dei rischi. Attività rivolte a stimare i rischi tecnici e di gestione. Vuole ridurre al minimo i rischi di sviluppo. In un

processo classico si tende a posticipare le cose difficili. Qui si cerca di anticipare ad esempio le parti nuove e di intergrazione più a rischio.

Strutturazione. Attività rivolte a costruire una o più rappresentazioni (strutture alternative) del sistema Costruzione e rilascio. Attività di sviluppo, effettuata secondo un modello generico (cascata, evolutivo...) Valutazione da parte del cliente. Attività rivolte a ricevere le reazioni del cliente su quanto fin qui realizzato (nei primi

giri della spirale si creano “idee” o “proposte”, nei successivi anche “prodotti” o “prototipi”)Nella prima fase c’è la fattibilità etc. Vuol dire che man a mano che ci allontaniamo dal centro andiamo verso la codifica e il test. Ma qui ogni volta si ricomnicia da capo con un subrìstrato sempre più grande.

Il modello a spirale, a differenza degli altri, tiene conto dei rischi. Rischio è evento imprevisto che può causare problemi o difficoltà

Esempio: Stiamo usando un compilatore per un nuovo linguaggio. C'è il rischio che il compilatore sia bacato. I rischi sono conseguenza di informazioni insufficienti. Si risolvono acquisendo maggiori informazioni per ridurre l'incertezza.

Vantaggi del Modello a Spirale Svantaggi del Modello a Spirale

Valutazione esplicita dei rischi Adatto allo sviluppo di sistemi complessi di grandi

dimensioni Interazione con il cliente ad ogni giro della spirale

La stima dei rischi richiede competenze specifiche Se i rischi non vengono valutati correttamente,

potranno sorgereproblemi nelle fasi successive Il modello è relativamente nuovo e poco sperimentato

Processo agile (usato in open source)“Quello che lei dovrebbe fare è realizzare una pila il più rapidamente possibile, prendere scorciatoie, fare tutto il possibile per portarla a termine in tempi rapidi. Poi la collauderete e non funzionerà. Poi scoprirete perché non funziona e ne costruirete un’altra che funzionerà” - Enrico Fermi -


29

Nel mondo Open Source è difficile controllare persone e processi. Ecco perché sono nati i cosiddetti "processi agili" (tra i più noti,eXtreme Programming).Lo sviluppo agile pone l’enfasi sulla pianificazione adattiva (tiro di prova, aggiusti il tiro, tiri ancora ...), la consegna rapida ai clienti e la capacità di reagire e adifficoltà inaspettate.

Manifesto per lo Sviluppo Agile di Software (http://agilemanifesto.org/iso/it/manifesto.html)

Stiamo scoprendo modi migliori di creare software,sviluppandolo e aiutando gli altri a fare lo stesso.Grazie a questa attività siamo arrivati a considerare importanti:

Gli individui e le interazioni più che i processi e gli strumentiIl software funzionante più che la documentazione esaustivaLa collaborazione col cliente più che la negoziazione dei contrattiRispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra,consideriamo più importanti le voci a sinistra.

I processi agili si prestano ad essere male interpretati. Semplificatori inesperti possono usarli come alibi per gettarsi subito a creare codice senza prestare attenzione ai dettagli alla documentazione. I processi agili, in realtà, sono molto disciplinati, essendobasati su pratiche rigorose e misurabili, e sulla trasparenza degli avanzamenti lavoro e dei risultati nei confronti di tutti i partecipanti al progetto.Non a caso, la maggioranza degli autori più rilevanti del software engineering "tradizionale" guarda ai processi agili in modo positivo.

Che cos’è l’Agilità? Reazione efficace (rapida e adattiva) ai cambiamenti Comunicazione efficace fra tutti gli stakeholder Assorbimento del cliente nel team di sviluppo Organizzazione del team che lo ponga in diretto controllo del proprio lavoro

Producendo … Consegne incrementali e frequenti di software Ogni iterazione è un piccolo progetto a sé stante: pianificazione (planning), analisi dei requisiti, analisi,

implementazione, test e documentazione. Alla fine di ogni iterazione il team deve rivalutare le priorità di progetto

I Processi agili sono : Guidati dalle descrizione del cliente di che cosa gli serve (scenario) Basati sull’assunzione che i piani hanno vita breve Sviluppano software in maniera iterativa con forte enfasi sulle attività di costruzione Producono e consegnano molteplici incrementi software Si adattano ai cambiamenti

http://www.felicepescatore.it/alm/112-agile-un-attimo-ma-non-somiglia-al-modello-a-spirale

Scrum (wikipedia) Scrum è un framework agile per la gestione del ciclo di sviluppo del software, iterativo ed incrementale, concepito per gestire progetti e prodotti software o applicazioni di sviluppo, creato e sviluppato da Ken Schwaber e Jeff Sutherland. Il termine Scrum è mutuato dal termine del rugby che indica il pacchetto di mischia ed è evidentemente una metafora del team di sviluppo che deve lavorare insieme in modo che tutti gli attori del progetto spingano nella stessa direzione, agendo come un'unica entità coordinata.

CaratteristicheIn maniera molto sintetica Scrum è un framework di processo che prevede di dividere il progetto in blocchi rapidi di lavoro (Sprint) alla fine di ciascuno dei quali creare un incremento del software. Esso indica come definire i dettagli del lavoro da fare nell'immediato futuro e prevede vari meeting con caratteristiche precise per creare occasioni di ispezione e controllo del lavoro svolto.


https://it.wikipedia.org/wiki/Rugby

https://it.wikipedia.org/w/index.php?title=Jeff_Sutherland&action=edit&redlink=1

https://it.wikipedia.org/w/index.php?title=Ken_Schwaber&action=edit&redlink=1

https://it.wikipedia.org/wiki/Software

https://it.wikipedia.org/wiki/Ciclo_di_vita_del_software

https://it.wikipedia.org/wiki/Metodologia_agile

http://www.felicepescatore.it/alm/112-agile-un-attimo-ma-non-somiglia-al-modello-a-spirale

30

Lo sprint è un'unità di base dello sviluppo in Scrum ed è di durata fissa, generalmente da una a quattro settimane. Ogni Sprint è preceduto da una riunione di pianificazione in cui vengono identificati gli obiettivi e vengono stimati i tempi.Scrum utilizza un metodo iterativo ed un approccio incrementale per ottimizzare la prevedibilità ed il controllo del rischio.Sono tre i pilastri che sostengono ogni implementazione del controllo empirico di processo.

Trasparenza Gli aspetti significativi del processo devono essere visibili ai responsabili del lavoro. La trasparenza richiede che quegli aspetti siano definiti da uno standard comune in modo tale che gli osservatori condividano una comune comprensione di ciò che viene visto.

Ispezione Chi utilizza Scrum deve ispezionare frequentemente gli artefatti prodotti ed i progressi realizzati verso il conseguimento degli obiettivi prestabiliti, individuando in tal modo precocemente eventuali difformità rispetto a quantosi intende realizzare.

Adattamento Se chi ispeziona verifica che uno o più aspetti del processo di produzione sono al di fuori dei limiti accettabili e che il prodotto finale non potrà essere accettato, deve intervenire sul processo stesso o sul materiale prodotto dalla lavorazione.

Ogni giorno durante lo Sprint, viene tenuta una riunione di comunicazione del team di progetto. Questo meeting viene chiamato "daily scrum", o "daily standup" ed ha un insieme di regole specifiche, tra cui:

L'incontro inizia puntualmente anche se qualche membro del team è assente

La durata del meeting è fissata (timeboxed) al tempo massimo di 15 minuti Si partecipa rimanendo in piedi, per non dare modo ai partecipanti di

distrarsi ed isolarsi come accade nelle riunioni "tradizionali"Durante l'incontro quotidiano, ogni membro del team risponde a tre domande:

Che cosa è stato fatto dopo l'ultima riunione? Che cosa si farà prima della prossima riunione? Quali sono gli impedimenti / ostacoli incontrati?

daily scrum- daily standup

Verifica 1 - Lacoop4u

Il problema: La cooperativa “Lacoop4u” (fondata nel 2001) e' costituita da 40 soci, ognuno dei quali e' proprietario di un negoziodi Ferramenta e/o Casalinghi. La cooperativa svolge la funzione di magazzino all'ingrosso per gli affiliati, cioè è in grado di ottenere i prodotti di consumo (ordinati dai soci) a prezzi favorevoli. La cooperativa vuole finalmente dotarsi di un applicativo Web in grado di raccogliere gli ordini dei soci in modo automatico.

Obiettivo: L’applicativo Web deve permettere ad ogni utente (i soci) di accedere al sistema, previa autenticazione, consentendo di controllare i prodotti che il magazzino ha a disposizione. Inoltre al sistema è richiesta la possibilità di gestire le anagrafiche dei clienti, dei fornitori e di ogni prodotto presente in magazzino.L’applicativo deve essere di facile comprensione e utilizzo.

A questo scopo “Lacoop4u” emette una gara di appalto in cui è richiesto di fornire un progetto software del sistema.

Alla gara di appalto ciascuno di voi decide di partecipare con la propria società (ad esempio “Bionda-Techno & Co.”). Per questa ragione ciascun studente deve: Progettare il sistema usando la metodologia a cascata:Illustrare il modello usato con un disegno e una legenda che lo spieghiPer ogni fase citare esplicitamente cosa riceve in ingresso e cosa produce in uscitaSoffermarsi sui lati positivi e negativi di questo modello

Progettare il sistema usando la metodologia a spirale:Illustrare il modello usato con un disegno e una legenda che lo spieghiPer ogni fase citare esplicitamente cosa riceve in ingresso e cosa produce in uscitaComparare questo modello con il precedente spiegandone i miglioramenti

NB l’esposizione deve essere fatta in modo sintetico, rispettando esattamente i punti citati, nella successione con cui sono stati espressi.


https://it.wikipedia.org/w/index.php?title=Timeboxing&action=edit&redlink=1

https://it.wikipedia.org/wiki/File:Daily_sprint_meeting.jpg

31

_________________________________________________________________

Verifica 2 - Hotmug2.0

Il problema: La società di distributori per bevande calde, Hotmug2.0, vuole progettare un innovativo sistema chepermetta di acquistare la bevanda tramite un’app (client) che, su cellulare, permetta al cliente di scegliere la bevanda e acui viene scalato dal credito del cellulare il costo.Il cellulare si collega, via Bluetooth o Wi-Fi, a un server presente nel distributore, in grado di ricevere dal client la richiestadella bevanda tramite un codice predefinito.

Il bando:A questo proposito la società Hotmug2.0 emette un bando che prevede la costruzione di un’app che abbia un’interfacciautente adeguata, comoda ed efficiente per la scelta della bevanda e la connessione al server. L’app deve prevedere lapossibilità di scegliere la bevanda (massimo 10 bevande, divise per tipologia), lo zucchero e quanto altro può servire adiscrezione della società che fornisce il progetto.

Il progetto:La vostra società (ad es. Rossinet, JocaConNoi, Applescom,…) vuole partecipare al bando e propone uno studio di fattibilitàdel progetto usando la metodologia a spirale.

1. (2.5 punti) Dopo aver fatto tutte le premesse che ritiene giuste e che partano dagli studi fatti, lo studente proponga:2. (5 punti)

2.1 Un disegno e una legenda che illustri tutte le fasi dello sviluppo del progetto2.2 Per ogni fase citare esplicitamente cosa riceve in ingresso e cosa produce in uscita2.3 Disegnare il prototipo che si vuole proporre2.4 Precisare i linguaggi usati nella fase di implementazione con tutte le caratteristiche che si vogliono evidenziare

3. (2.5 punti) Alla fine fare un'analisi critica del progetto, comparando in una tabella, vantaggi e svantaggivantaggi svantaggi


Verifica 3 - Sweethouse

Il problema: La società di progettazione edile Sweethouse vuole fornire i suoi clienti di un app che li informi dello statoavanzamento dei lavori di progettazione della propria casa o appartamento. Di ogni appartamento interessano l’indirizzo, il nome, i locali che lo compongono e come questi sono connessi tra loro. Inoltre, diciascun locale, interessano il codice identificativo (di 3 caratteri), i metri quadri ed una descrizione testuale (salotto, bagno,cucina,…).

NOTA Un appartamento è inizialmente in preparazione, poi alla fine dei lavori diviene pronto per la consegna; a questopunto possono essere richiesti ulteriori lavori (e quindi torna ad essere in preparazione) o può essere consegnato.

Sweethouse commissiona al vostro studio informatico (ad es. Zilysoft o Aspecom) uno studio di fattibilità del progetto erichiede di:

1. (3.5 punti) Progettare il sistema usando la metodologia a cascata:1 Illustrare il modello usato con un disegno e una legenda che lo spieghi2 Per ogni fase citare esplicitamente cosa riceve in ingresso e cosa produce in uscita

4. (3.5 punti) Progettare il sistema usando la metodologia a spirale:1 Illustrare il modello usato con un disegno e una legenda che lo spieghi2 Per ogni fase citare esplicitamente cosa riceve in ingresso e cosa produce in uscita


32

5. (3 punti) Alla fine fare un'analisi critica dei due modelli realizzati comparando , in una tabella, vantaggi e svantaggi diciascuno, relativamente al caso proposto:

ProgettoSweethouse

vantaggi svantaggi

cascata

spirale


Verifica 4 - My-s

Il problema: La società My-s proprietaria di una grande azienda agricola produttrice di mais non transgenico, vuoleprogettare un’applicazione per il monitoraggio delle proprie coltivazioni. In questo scenario, molti sensori sono installati invarie posizioni, vicino alle coltivazioni, in modo da rilevare temperatura, luce ed umidità del terreno. Se la temperatura diun certo lotto di mais scende sotto una certa temperatura, un messaggio di avviso viene presentato sullo schermodell'interfaccia e viene indicata l’esatta posizione geografica. Analoga situazione si presenta se le piante di mais sonoesposte a troppa luce solare o a una temperatura elevata oppure se il terreno diventa troppo umido o troppo secco.

Il bando:A questo proposito la società My-s emette un bando che prevede la costruzione di un’applicazione Web che abbiaun’interfaccia utente adeguata, comoda ed efficiente per il monitoraggio dell’impianto descritto nel problema. Adesempio, se il livello di umidità del terreno è basso, potrebbe essere necessario avvisare l’agricoltore che è necessarioattivare il sistema di irrigazione. L’agricoltore, a conoscenza di altre circostanze come ad esempio le previsionimetereologiche, può prendere una decisione appropriata.

In particolare l’applicazione deve prevedere: la possibilità di riconoscere l’utente e di fornire gli accessi relativi la possibilità di monitorare il sistema e di ricevere warning (livello di attenzione) ed allarmi la possibilità (solo se abilitato) di attuare comandi a distanza per l’irrigazione

Il progetto:La vostra società (ad es. Rossinet, FotiLab,…) vuole partecipare al bando e propone uno studio di fattibilità del progettousando la metodologia a spirale.

(2.5 punti) Lo studente, dopo aver fatto tutte le premesse che ritiene giuste e aver citato le caratteristiche chedistinguono una metodologia a spirale da una metodologia a cascata, proponga:

(5 punti) o Un disegno e una legenda che illustri tutte le fasi dello sviluppo del progettoo Per ogni fase citare esplicitamente cosa riceve in ingresso e cosa produce in uscitao Disegnare il prototipo che si vuole proporreo Precisare i tools usati nella fase di implementazione con tutte le caratteristiche che si vogliono evidenziare

(2.5 punti) Alla fine fare un'analisi critica del progetto, comparando in una tabella, vantaggi e svantaggivantaggi svantaggi



33

Requisiti e specifiche

I requisiti (cosa)Cosa sono i requisiti?Intuitivamente un requisito è ciò che ci aspettiamo dal sistema, ciò che andiamo a realizzare. Un progetto ha successo se soddisfa i requisiti! Descrivere male i requisiti porta a risultati fallimentari.Qui non parliamo di come (piattaforme, codici, linguaggi) ma di COSA un sistema debba fare, le sue proprietà essenziali ed i vincoli a cui deve rispondere.

I requisiti sono le caratteristiche che utente e committente desiderano che siano presenti in un prodotto software da realizzare, o in altre parole, cosa è richiesto dall’utente finale.

L’obiettivo di un progetto di sviluppo software, quando si realizza un nuovo sistema o si apportano modifiche ad un sistema già esistente, è sempre realizzare un prodotto che soddisfi i requisiti

Utente e committente valuteranno il risultato sulla base del fatto che soddisfi o meno i requisiti.

Analisi dei requisiti: Il committente esprime una serie di vincoli Il fornitore formula una o più ipotesi di soluzione, in grado di rispondere, in tutto o in parte, ai requisiti

espressi Il committente sceglie tra le soluzioni proposte quella migliore (dal suo punto di vista) in termini di rapporto

tra costi e benefici, e stipula un contratto con il committente

Punti critici: Fase difficile e critica (una specifica sbagliata porta necessariamente al fallimento del progetto) . Fraintendimenti tanto più probabili quanto più lontane sono le culture di sviluppatore e utente finale Necessità di verificarla

Cosa occorre: Precisione, chiarezza, non-ambiguità Coerenza Completezza Interna Esterna Incrementalità

Interfaccia La macchina interagisce con l’ambiente ricevendo input e producendo output La specifica descrive la relazione fra input e output


34

Esempi: cosa deve apparire a video in seguito al clic su un pulsante quale segnale di controllo deve essere inviato a un attuatore in seguito a un determinato segnale rilevato da un sensore Esempi di ambiguità:

“In assenza di richieste, l’ascensore entra in uno stato di attesa di richiesta” Bisogna definire lo stato di attesa di richiesta.

Specifica di un sistema real-time: “Il messaggio dovrà essere triplicato. Le tre copie dovranno essere spedite attraverso tre canali fisici diversi. Il ricevitore dovrà accettare il messaggio sulla base di una politica di votazione “due su tre”.” Se si ricevono due copie identiche, bisogna aspettare la terza?

Difficile soddisfare i requisisti perché: interpretazione del problema diversa (le controparti non sanno esattamente cosa vogliono). Scritti mali con modi

di esprimersi diversi Fattori politici e organizzativi possono influenzare i requisiti del sistema I requisiti sono inevitabilmente soggetti al cambiamento e correggere i requisiti è traumatico e costoso diversi stakeholder (cioè chiunque ha interesse nel progetto: committente, progetto, implementazione.

Marketing. Guadagno…) hanno un diverso tipo di requisiti con contraddizioni, ad esempio: costo/qualità. Funzionalità/semplicità. Usabilità/funzionalità

Per descrivere i requisiti il fornitore produce un documento dei requisiti che: deve essere leggibile e facilmente modificabile deve essere completo e consistente: devono cioè essere considerate tutte le funzionalità richieste dal cliente e

non vi devono essere requisiti contraddittori deve essere verificabile: quando si descrive un vincolo oppure un comportamento si deve poter verificare se è

soddisfatto – “il sistema deve essere facile da usare facendo pochi errori” la frase non è adeguata poiché descrive qualcosa di non verificabile – “l’utente medio deve sapere usare il sistema dopo due ore di addestramento e non deve fare poi più di due errori al giorno” è corretta perché descrive qualcosa di verificabile

Deve definire un modello astratto del sistema finale ◦ Comportamento funzionale del sistema (descrizione funzionale dei servizi forniti dal sistema, delle operazioni

accessibili all’utente) ◦ Vincoli: prestazioni, protezione, sicurezza, usabilità, ecc. ◦ Descrizione dell’hardware necessario ◦ Database prescelto ◦ Informazioni per il mantenimento del sistema (ad esempio release periodici, manutenzione per

malfunzionamenti) ◦ Glossario per la spiegazione dei termini tecnici

I principali fattori di insuccesso dei progetti (I principali fattori di insuccesso dei progetti non riguardano gli aspetti tecnici): Problemi manageriali – mancanza di supporto da parte della direzione – mancanza di risorse – mancanza di

pianificazione Problemi sui requisiti (soprattutto) – requisiti incompleti – mancato coinvolgimento degli utenti – attese

irrealistiche – cambiamento dei requisiti in corso d'opera – progetti cancellati perché non più utili

Domande utili per scrivere i requisiti (http://www.cs.unibo.it/~cianca/wwwpages/labspo/2.pdf) Cosa deve fare il software? Che interfacce ha con i suoi utenti, con l’hw, con altro sw? Che prestazioni deve esibire il sw? Quali attributi (es. portabilità) dovrà avere? Quali vincoli dovrà soddisfare?

Struttura del documento dei requisiti Introduzione (definizione dei requisiti) – Descrivere perché si costruisce il sistema e come risponde ai bisogni

dell’organizzazione Requisiti funzionali – Descrivere in dettaglio i servizi da fornire. Definire i vincoli sul sistema e sul suo processo di sviluppo Evoluzione del sistema – Definire le assunzioni critiche su cui si basa il sistema ed anticipare i possibili

cambiamenti


35

Glossario Definire i termini tecnici che si usano Indici generale e analitico

SCHEDA PROGETTO (requisiti)Esplicitare gli obiettivi: formalizzare, codificare, santificare, mostrare, spiegare cosa c’è da fare!

Progetto n.Progettista

Scheda n. /ndata

Titolo

Obiettivi

Descrizione

Fasi del progetto e tempistica (allegare diagramma)

Risorse e strumenti

Risultati attesi in termini di prodotto/servizi e rapporto costo/benefici

Note aggiuntive

Firma

Per un approfondimento si veda: http://www.slideshare.net/rpolillo/template-documento-dei-requisiti

SpecificheTermine usato con significati diversi a seconda del contesto.

Specifica di un progetto: accordo fra progettista e implementatori . Cosa deve fare il sistema per soddisfare i requisiti

Specifica di un modulo: accordo fra i programmatori che lo useranno e quelli che lo implementano

Le specifiche di progetto sono la riformulazione dei requisiti in modo formalizzato per l’utilizzo nel processo interno del fornitore, in modo da definire precisamente che cosa deve fare il software da produrre

L’obiettivo di un processo di sviluppo software è realizzare un prodotto che soddisfi le specificheTecno2 - L’ingegneria del software – paolo macchi - ISIS Facchinetti rel. 19.02.05

36

Il risultato del processo di sviluppo verrà valutato sulla base del fatto che soddisfi o meno le specifiche

Specifiche devono essere: Precise

Esempio ambiguo: “selezione”: non mi chiarisce la forma dell’area da utilizzare, non definisce alcune possibilità ex. CTRL, SHIFT

Complete: definire tutti i termini (glossario) (interna), inoltre documentare i requisiti necessari (esterna) Consistente: garantisce di essere soddisfatta in modo univoco

◦Esempio inconsistente: le parole sono indivisibili? Se è più lunga della riga cosa faccio???? Potrei avere una soluzione corretta ma non soddisfa l’utente

Incrementale: avere più bozze sempre più dettagliate. Aggiornare le specifiche in modo incrementale

Stili di specifica

Il documento delle specifiche descrive ciò che farà il software e le sue parti/moduli. Le specifiche informali, che sono le più diffuse, sono formulate in linguaggio naturale, anche con l’ausilio di tabelle e

grafici. Per ottenere maggiore precisione si seguono degli standard ma non vi è una vera e propria simbologia matematica

Le specifiche formali si basano su formalismi matematici, sono espresse in un linguaggio con sintassi e semantica definite formalmente. Precise e chiare, cioè Dettagliate, senza tralasciare elementi importanti. Il linguaggio naturale si utilizza per commentare e chiarire le notazioni utilizzate

Semi formali: usano notazioni grafiche per cui la semantica non è sempre precisamente definita

Esempio di notazione informale/semiformale (un sensore su un ascensore):


37

Una figura geometrica: Ellisse - come la descrive il giardiniere (informale) :la costruzione di un’ellisse consiste nel piantare nel terreno i due pioli. “Ai due pioli si lega la cordicella in modo tale che la parte libera risulti più lunga della distanza fra i pioli, ed uguale all'asse maggiore dell'ellisse che si vuole ottenere. Con il punteruolo si tende la funicella e lo si fa scorrere sul terreno badando che i due lati della funicella risultino sempre tesi. La traccia che ne deriva sarà costituita da la cui somma delle distanze dai due pioli è costante e coincide con la lunghezza dellaparte libera della funicella. .” (wikipedia)

- oppure con una proprietà geometrica (formale): l'ellisse è il luogo dei punti la cui somma delle distanze da due punti fissi detti fuochi è costante:

Linguaggi di specifica

Molti sono i linguaggi di specifica usate. Qui ne mostriamo, come esempio, alcune.

1. Diagrammi di flusso dei dati : operazionale e semiformale . Notazione grafica. Hanno avuto enorme successo in passato.

Processi, unità di memoria, flussi, entità esterne connesse


38

2. Macchine a stati finiti (automi) : modello di specifica operazionale. Insieme di operazioni. Modello formale (isieme finito di stati (Q), insiseme ingressi I, elementi di transizione (trasforma stato/ingresso in stato)) e grafico.

3. Specifiche algebriche: dominio e operazioni sul dominio

sorts (dominio) + operazioni (operations)

Documento dei requisiti e documento delle specifiche possono sembrare simili, in realtà vi sono delle differenze sostanziali

Documento dei requisiti Documento delle specifiche

Il documento dei requisiti viene fornito all’utente– deve quindi essere comprensibile per l’utente –

viene utilizzato al momento del collaudo rappresenta uno strumento per il fornitore in

caso di contese con il cliente

Il documento delle specifiche viene utilizzato internamente dal produttore

non viene mostrato all’utente può essere quindi molto tecnico

Esempio di specifica


39

Esempi: Requisiti – specifiche

Un esempio Cambio gommeCliente: un treno di gomme invernali per Ghiaccio e neveFornitore-Cliente: (requisiti)

spazi di frenata decisamente più contenuti tenuta di strada più elevata, comportamento del veicolo più lineare e prevedibile maggiore direzionalità in curva e performance migliori il vantaggio prestazionale delle gomme invernali sulle estive è notevole quando le temperature cominciano a scendere sotto i 7 gradi.

Fornitore-Progettista: (specifiche di progetto) pneumatici marchiati M+S caratteristiche tecniche:

parcheggio controllatoSe io (utente ) devo entrare in un parcheggio, ciò che mi interessa è che la sbarra si alzi. Questo è un requisito.Non mi interessa se l’apertura della sbarra è controllata da un sistema software che deve aprire la sbarra (leggere un sensore, azionare un attuatore) e garantire i requisiti.Abbiamo un sistema di controllo che comprende sensori e attutori :


40

Requisiti : ciò che l’utente chiede al sistema Specifiche di progetto : cosa deve fare il sistema per soddisfare i requisiti (Il progettista si occuperà solo delle

specifiche di progetto.)

Definizione- Dominio Applicativo (D.A.) -> parcheggio

Veicolo autorizzato Varco aperto Parcheggio libero

- Sistema di controllo -> controllo del parcheggio

controllore Sensore in ingresso attivo Attuatore (“Apri varco “: inviato alla sbarra da parte del sistema software) Tessera valida

Il requisito è quello che interessa all’utente e che, cioè, IL VARCO SI APRA! Quando si apre il varco?


41

Metodologie per la progettazione di sistemi

Progetto= Come fare (e non cosa fare).

La Progettazione (detta anche la fase di Design) è il processo che porta alla definizione ingegneristica di ciò che deve essere realizzato. Attività che fa da ponte fra i requisiti e l’implementazione del software (dal “cosa” al “come”). Il progetto deve:

soddisfare i requisiti espliciti ed impliciti, basandosi sulle specifiche deve essere una guida leggibile e comprensibile a chi effettuerà la codifica deve dare un quadro completo del software per la sua implementazione, contemplando dati, funzioni e interfacce possedere un’architettura modulare con modelli riconoscibili durante la fase di progettazione si delineano solamente gli aspetti di alto livello, generali e piuttosto astratti della

programmazione: la fase si sviluppo (coding – trasformazione in codice) sarà successiva e inizierà al completamento della fase di progettazione.

Le tecniche di progettazione si basano su tecniche per tradurre il modello in progetto, ci sono REGOLE e FASI che, però, si basanosu due modi di pensare e agire: ASTRAZIONE e RAFFINAMENTO.

Raffinamento e astrazione possono essere considerate attività di tipo complementare. Mediante l'astrazione, il progettista specifica procedure e dati eliminando i dettagli di basso livello. Mediante raffinamento, i dettagli emergono via via.

ASTRAZIONEE’ una delle fasi più importanti e difficoltose.L’astrazione è l’atto di dare una descrizione del sistema ad un certo livello trascurando i dettagli inerenti i livelli sottostanti.A livelli di astrazione elevati si utilizza di preferenza un linguaggio vicino al contesto del problema che il sistema dovrà risolvere (p.es. la specifica)A livelli più bassi di astrazione il linguaggio si formalizza sempre di più fino ad arrivare, al livello più basso o di astrazione nulla, al codice sorgente

RAFFINAMENTO Il metodo di raffinamento utilizza tecniche di scomposizione per passare da astrazioni funzionali ad alto livello alle linee di codice.

Si compone di due fasi: diversificazione e convergenza Durante la diversificazione il progettista acquisice il materiale grezzo del progetto (componenti, possibilità di

realizzazione, conoscenze) per individuare le possibilità realizzative Nella fase di convergenza sceglie e combina gli elementi disponibili per arrivare ad un prodotto finale

FASI del progetto Comprensione del problema Guardare al problema da diversi punti di vista Identificare una o più soluzioni Valutare le possibili soluzioni e scegliere la più appropriata in base alle risorse a disposizione e all'esperienza del

progettista Descrivere in astratto le soluzioni

◦ Utilizzare notazioni grafiche, formali o intuitive per descrivere le componenti del progetto◦ Ripetere il processo per ciascuna astrazione individuata, fino a quando il progetto è espresso in termini

primitivi. In pratica procedere a livelli, progettando in dettaglio le componenti e le loro sotto-componenti fino a quandosi raggiunge un livello in cui le componenti non possono più essere ulteriormente suddivise


42

REGOLE Empiriche di Progetto

Il progettista non deve procedere col paraocchi Bisogna sempre essere aperti all’utilizzo di soluzioni alternative Il progetto deve sempre essere riconducibile al modello concettuale Evitare di riscoprire l’acqua calda Riutilizzare ove possibile schemi o strutture dati già sviluppati in altri progetti Il progetto finale deve apparire uniforme ed integrato Definire da subito regole di formato e di stile se si lavora in team Il progetto deve poter accogliere modifiche Un software ben congegnato dovrebbe poter reagire a condizioni inusuali e arrestarsi, se necessario, in modo

regolato Il progetto NON E’ la stesura del codice (e viceversa!): Il livello di astrazione deve mantenersi più elevato Al termine del progetto va sempre prevista una revisione formale che lo riesamini nel suo complesso. La

revisione non deve perdersi nei dettagli sintattici

Qualità di un progetto

La qualità dipende da specifiche priorità di tipo organizzativo Un "buon" progetto potrebbe essere il più efficiente, il meno costoso, il più mantenibile, il più affidabile... Gli attributi che descriviamo ora hanno a che fare con la mantenibilità del progetto Un progetto mantenibile può essere adattato modificando funzionalità esistenti o aggiungendone di nuove. Il progettodovrebbe rimanere comprensibile, e i cambiamenti dovrebbero avere effetto locale

La Specifica del Progetto

La specifica del Progetto è il documento che descrive il progetto finale con questo formato Descrizione della portata globale del progetto ricavata dalla specifica dei requisiti Descrizione del progetto dei dati: struttura del DB, file esterni, dati interni, riferimenti fra dati Descrizione dell’architettura con riferimento ai metodi utilizzati per ricavarla, rappresentazione gerarchica dei moduli Progetto delle interfacce interne ed esterne, descrizione dettagliata dell’interazione utente/sistema con eventuale

prototipo Descrizione procedurale dei singoli componenti in linguaggio naturale

1 Disegno Architetturalea. Identificare e documentare i sottosistemi e le loro relazioni

2 Specifica astrattaa. Specifica i servizi forniti da ciascun sottosistema, e i vincoli sotto cui il sottosistema deve operare. La specifica

delle interfacce deve essere non ambigua dato che deve consentire di definire i sottosistemi ignorando come operano al loro interno

3 Disegno delle interfaccea. Descrive l'interfaccia dei sottosistemi verso altri sottosistemi.

4 Disegno dei componenti


43

a. Allocare i servizi ai diversi componenti e definire le interfacce di questi componenti5 Disegno delle strutture dati

a. Specificare come sono fatte le strutture dati6 Disegno degli algoritmi

a. Specificare gli algoritmi utilizzati

Progettazione top-down e bottom-up

La progettazione di un sistema software e lo sviluppo successivo può essere affrontata in due modi sostanzialmente opposti.Nel top-down si parte da una visione generale del sistema e si scende , man mano, verso parti più piccole e dettagliate che,a loro volta, possono essere ulteriormente dettagliate fino alla semplificazione finale (divide et impera). In alto c’è il “problema da risolvere” e più in basso i “sottoproblemi” che lo compongono.

Questo è opposto della progettazione bottom-up, nella quale “parti individuali del sistema sono specificate in dettaglio, e poi connesse tra loro in modo da formare componenti più grandi, a loro volta interconnesse fino a realizzare un sistema completo”.

Top down in psicologia“L'elaborazione bottom-up e top-down sono i sistemi utilizzati dalla nostra mente in determinati ambiti. L'elaborazione bottom-up (detta anche elaborazione guidata dai dati) avviene quando ad esempio entrando nella tua aula ti balza all'occhio un particolare colore rosso. Partendo dalla semplice immagine che colpisce la tua retina questa informazione risale tutti i "livelli cognitivi" che potrebbero riguardare ad esempio un certo ricordo che tu hai di quel particolare colore, le emozioni che ti suscita e via dicendo... Si chiama appunto bottom-up perchè dai primi e basilari livelli percettivi l'informazione risale ai vertici degli schemi cognitivi. L'elaborazione top-down (elaborazione guidata dai concetti) avviene quando tu, entrando nella tua aula sai di dover cercare un amico che ti aspetta, quindi attivi tutti i circuiti adibiti alla percezione del tuo amico e inibisci tutti gli altri, quindi da uno schema complesso arriverai a percepire la semplice immagine del tuo amico. “

Top-downIl problema viene partizionato ricorsivamente in sottoproblemi fino a che si identificano dei sottoproblemi trattabili. la progettazione inizia specificando parti complesse e suddividendole successivamente in parti più piccole. Eventualmente,i componenti sono specificati quanto basta per la codifica.


44

In teoria, la progettazione top-down richiede di iniziare con il componente radice della gerarchia, e procedere verso il basso livello dopo livello. In pratica, la progettazione di sistemi di grosse dimensioni non è mai completamente top-down. Alcuni rami sono sviluppati prima di altri. I progettisti riutilizzano l'esperienza (e talvolta le componenti) durante il processo di progettazione.

La tecnica per la scrittura di un programma mediante l'utilizzo dei metodi top-down indica di scrivere una procedura principale che indica dei nomi per le principali funzioni di cui avrà bisogno. In seguito, il gruppo di programmazione esaminerà i requisiti di ognuna di queste funzioni ed il processo verrà ripetuto. Queste sotto-procedure a comparto eseguiranno eventualmente azioni così semplici che porteranno ad una codifica semplice e concisa. Quando tutte le varie sotto-procedure sono state codificate, il programma è realizzato.

programmazione top-down

Vantaggi: Il gruppo di programmazione resta focalizzato sull'obiettivo. Ognuno conosce il proprio compito. Nel momento in cui parte la programmazione, non vi sono più domande. Il codice è semplice da seguire, dato che è scritto in maniera metodica e con uno scopo preciso.

Svantaggi: La programmazione top-down può complicare la fase di test, dato che non esisterà un eseguibile finché non si arriverà

quasi alla fine del progetto. Tutte le decisioni dipendono dall'avvio del progetto ed alcune decisioni non possono essere fatte sulla base del dettaglio


45

delle specifiche.

Bottom-up

La progettazione Bottom-up parte dal basso e va verso l’alto. Si generano o riutilizzano funzioni elementari e li si combinano in compiti più complessi risalendo fino alla risoluzione del problema. Come per la progettazione di un sistema che utilizza il lego, si creano mattoncini elementari, piccoli pezzi di programma, che sonofacili da progettare, scrivere e testare. Li si collegano tra loro producendo sistemi più complessi, fino ad arrivare all’obiettivo. Ciò comporta spesso la produzione e l’accesso a “librerie” che svolgono compiti comuni, aumentando man mano il repertorio degli strumenti a disposizione e, di conseguenza, il livello di produzione.

”Building blocks are an example of bottom-up designbecause the parts are first created and thenassembled without regard to how the parts will workin the assembly” (Wikipedia)

Top-down vs bottom-up

I moderni approcci alla progettazione software tipicamente combinano sia la tecnica top-down che quella bottom-up. Sebbene la comprensione del sistema completo è tipicamente considerata necessaria per una buona progettazione che conduce teoricamente ad un approccio top-down, la maggior parte dei progetti software cercano di fare uso di codice già esistente ad alcuni livelli. I moduli pre-esistenti danno alla progettazione una tendenza bottom-up.

Alcuni approcci di progettazione operano progettando un sistema parzialmente funzionale che viene completamente codificato, poi questo sistema viene quindi espanso fino a soddisfare tutti i requisiti di progetto.

L'approccio top-down enfatizza la pianificazione ed una completa comprensione del sistema. È ovvio che nessuna codifica può iniziare finché non si è raggiunto almeno un sufficiente livello di dettaglio nella progettazione di una parte significante del sistema. Questo, comunque, ritarda la fase di test delle ultime unità funzionali di un sistema finché una parte significativa della progettazione non è stata completata.

L'approccio bottom-up enfatizza la codifica e la fase di test precoce, che può iniziare appena il primo modulo è stato specificato.Questo approccio, comunque, induce il rischio che i moduli possano essere codificati senza avere una chiara idea di come dovranno essere connessi ad altre parti del sistema, e quel tipo di link potrebbe non essere facile. La riusabilità del codice è uno dei principali benefici dell'approccio bottom-up. La programmazione bottom-up agevola il test di unità, ma finché il sistema non si unisce non può essere testato nella sua interezza, e ciò causa spesso complicazioni verso la fine del progetto: "Individualmente ci siamo, insieme falliamo."

La progettazione top-down è stata sostenuta negli anni settanta. Il successo ingegneristico e gestionale di questo progetto condusse alla crescita dell'approccio top-down tramite IBM ed il resto dell'industria informatica. I metodi top-down erano i preferiti nell’informatica negli anni ottanta.

Il Divide et Impera e il top-down …Il Divide et Impera è la speranza di risolvere un problema irrisolvibile scomponendolo in un insieme di sottoproblemi egualmente irrisolvibili. Per esempio, come fare entrare cinque elefanti in una Volkswagen? Facendo accomodare i primi due sul sedile anteriore e sistemando gli altri tre in quello posteriore. Il principio del Divide et Impera ha come esatto


46

contrario quello dell'Orda Mongola (*).Il Divide et Impera ha molto a che vedere con l'approccio Top-Down: di fronte ad un compito complesso si individuano dei sottosistemi e se ne fissano le specifiche, che vengono poi passate ai gruppi di lavoro che li devono progettare e costruire. "si dà cioè per scontato che, se i sottosistemi soddisfanno le loro specifiche e sono connessi tra loro nel modo previsto, alloraanche il sistema globale soddisferà le sue specifiche. Quanto più complicato è il sistema, tanto meno probabile è che ciò accada". (si veda anche la legge di Murphy (****).

(*) Orda Mongola - E' la speranza di risolvere un problema complesso con la sola forza del numero. Si basa sull'idea che, se un muratore costruisce una casa in cento giorni, cento muratori possono farlo in un giorno; se un aereo attraversa l'Atlantico in quattro ore, due aerei possono farlo in due ore; se a una donna per mettere al mondo un figlio occorrono 9 mesi, a nove donne... E' l'esatto contrario del principio del Divide et Impera.L'applicazione del principio dell'Orda Mongola passa attraverso le leggi diMealy (***) e dei Mille Programmatori (**)

(**) Mille Programmatori (Legge dei) - Se assegnate mille programmatori a un progetto senza aver ben definito il disegno del sistema, otterrete un sistema di almeno mille moduli - anche se non ne dovrebbe contare più di cento.

(***) Mealy (Legge di) - Se un progetto ritarda, aggiungere una nuova persona al gruppo di lavoro consuma più risorse di quante ne produca.

(****) Murphy (Legge di) - Se qualcosa può andare storto, non mancherà di farlo.Di tutte le "leggi" è probabilmente quella che ha valore più universale: questo concentrato di pessimismo è stato enunciato nel 1949 da Ed Murphy, ingegnere aeronautico e capitano della US Air Force

Tratto da “Il Dizionarietto del Diavolo del DP” - di Emilio C. Porcelli

La Programmazione top-down/bottom-up

La tecnica per la scrittura di un programma mediante l'utilizzo dei metodi top-down prevede di scrivere una procedura principale che indica dei nomi per le principali funzioni di cui avrà bisogno. In seguito, il gruppo di programmazione esaminerà i requisiti di ognuna di queste funzioni ed il processo verrà ripetuto. Queste sotto-procedure a comparto eseguiranno eventualmente azioni così semplici che porteranno ad una codifica semplice e concisa. Quando tutte le varie sotto-procedure sono state codificate, il programma è realizzato.

MCD approccio Top Down

Come definire un modulo opportuno di date dimensioni? Ossia, come individuare la dimensione ottimale dei moduli che minimizza la somma dei costi di sviluppo e di integrazione?La risposta si trova nei metodi con cui si sviluppa un sistema basato su moduli. Meyer (1988) definisce cinque criteri per valutare un metodo di progettazione di software in base alla loro capacità di produrre efficientemente dei sistemi modulari

Scomponibilitào Un metodo che permette la scomposizione del problema in sottoproblemi : riduce la complessità

ComponibilitàTecno2 - L’ingegneria del software – paolo macchi - ISIS Facchinetti rel. 19.02.05

47

o Un metodo che permette l’assemblamento di componenti preesistenti migliora la produttività Comprensibilità

o Un modulo le cui interfacce con altri moduli siano minime è di più facile costruzione e modificabilità Continuità

o Modifiche ai requisiti del sistema che comportano solo modifiche a singoli moduli e non all’architettura generale sono di facile controllo

Protezioneo Se effetti anomali in un modulo non si propagano si ha un miglioramento della mantenibilità

Indipendenza Modulare Per ottenere una modularità effettiva i moduli devono essere indipendenti, ossia devono occuparsi di una funzione ben determinata nelle specifiche dei requisiti ed interagire con gli altri moduli solo tramite interfacce semplici L’indipendenza di un modulo può essere misurata in termini della sua coesione e dal suo accoppiamento con altri moduli

Il principio dell’information hiding il modulo non rende nota al mondo esterno una decisione ma la funzionalità che realizzaInformation hiding un modulo offre all’esterno un insieme di funzionalità senza rivelare come sono realizzate Ogni modulo deve nascondere una decisione ma deve fornire all’esterno certe funzionalità Ogni modulo offre all’esterno un certo numero di funzioni di interfaccia per manipolare l’entità astratta nascosta

nel modulo, senza però mai rilevare agli altri moduli la sua effettiva realizzazione Ogni modulo ha delle strutture dati private non accessibili se non tramite le funzioni di interfaccia.Viene così

risolto il problema dell’accoppiamento i moduli comunicano solamente per mezzo di funzioni di interfaccia e per mezzo dei loro parametri


48

Qual è la migliore strategia per lo sviluppo?Normalmente la definizione della gerarchia dei moduli avviene con un procedimento intermedio tra top-down e bottom-up. Non si attua in un solo passaggio ma in modo ciclico:

Inizialmente si segue una strategia prevalentemente top-down (che ben si adatta alla soluzione del problema) Si tiene in considerazione per il riutilizzo eventuale software già implementato o moduli per i quali risulta subito

chiaro che devono realizzare determinate funzionalità Si confrontano i moduli ottenuti con quelli esistenti: se si trovano moduli simili o già realizzati, si modifica il

progetto per riutilizzarli Il progetto viene visto e rivisto più volte

"… si può affermare che, nella costruzione di un nuovo algoritmo, è dominante il processo top-down, mentre nell’adattamento (a scopi diversi) di un programma già scritto, assume una maggiore importanza il metodo bottom-up." (N.Wirth)

Strategia di progetto orientata alle funzioni

Bisogna decidere cosa mettere nei moduli. Vi sono diverse strategie di progettoNella strategia orientata alle funzioni un modulo racchiude una funzionalità: è un metodo di razionalizzare la progettazione spesso seguito istintivamente :

Il progetto viene scomposto in un insieme di unità interagenti, ognuna corrispondente ad una funzione chiaramente definita. I moduli vengono quindi a coincidere con le decisioni

Questo approccio garantisce una coesione di tipo funzionale e, se la decomposizione è fatta bene, determina spesso un basso accoppiamento

La Struttura dei Dati definisce l’organizzazione, i metodi di accesso, il grado di associatività e le alternative di elaborazione per le informazioni.

Organizzazione e complessità dipendono dall’inventiva del progettista e dalla natura del problema. Esistono diverse strutture di base che possono essere combinate elemento scalare: entità di dati elementare bit, numero intero, numero reale, stringa vettore sequenziale: gruppo contiguo di elementi scalari omogenei spazio n-dimensionale (o matrice): vettore a 2 o più

dimensioni lista: gruppo di elementi connessi

La Procedura Software La gerarchia di controllo riassume le relazione gerarchiche tra i moduli ma non descrive la logica interna di ciascun modulo. La procedura software si concentra sui dettagli dell’elaborazione specificando la sequenza degli eventi, i punti di decisione e i

punti di chiamata ai moduli subordinati. Il flow-chart è una rappresentazione grafica della procedura software

Information Hiding Il principio dell’information hiding (occultamento dell’informazione) richiede che ciascun modulo sia definito in modo che le

sue procedure e le informazioni locali su cui agisce non siano accessibili ad altri moduli L’interazione con gli altri moduli deve avvenire solo tramite la sua interfaccia Il vantaggio principale sta nella facilità di modifica di ciascun modulo poiché non ci si deve preoccupare degli effetti collaterali

delle modifiche La definizione di moduli tramite la tecnica dell’information hiding può essere d’aiuto nell’identificare il punto di minimo costo

per la modularità del sistema


49

- Descrive l’organizzazione gerarchica dei moduli di un programma. Un esempio classico è la struttura ad albero con Call e Return

Un esempio di programmazione Top Down (funzionale)

Come esempio si applicherà il procedimento descritto alla risoluzione del seguente problema ():In una località geografica sono state rilevate ogni 2 ore le temperature di una giornata. Si vuole conoscere la temperatura media, l’escursione termica e lo scostamento medio dalla media.Si tratta di scrivere un programma che richiede alcune elaborazioni statistiche su una serie di valori. Si ricorda che la media aritmetica di una serie n di valori è data dal rapporto fra la somma dei valori della serie e il numero n stesso. L’escursione termica è in pratica il campo di variazione cioè la differenza fra il valore massimo e il valore minimo della serie di valori. Lo scostamento medio è la media dei valori assoluti degli scostamenti dalla media aritmetica, dove lo scostamento è la differenza fra il valore considerato della serie e la media aritmetica.La prima stesura del programma potrebbe essere la seguente:

Inizio Acquisizione temperature rilevate Calcolo media e ricerca massimo e minimo Calcolo escursione termica Calcolo scostamento medio Comunicazione risultatiFine

In questa prima approssimazione si sono evidenziati i risultati intermedi da conseguire affinché il problema possa essere risolto. Non si parla di istruzioni eseguibili ma di stati di avanzamento del processo di elaborazione: per il momento non c’è niente di preciso ma il problema proposto è stato ricondotto a 5 problemi ognuno dei quali si occupa di una determinata elaborazione. Viene messa in evidenza la sequenza delle operazioni da effettuare: l’escursione termica si può, per esempio, calcolare solo dopo la ricerca del massimo e del minimo.Si noti che ad ogni fase di lavoro è assegnato un compito specifico ed è quindi più facile la ricerca di un eventuale sottoprogramma errato: se lo scostamento medio è errato e la media risulta corretta è chiaro che, con molta probabilità, l’errore è localizzato nel penultimo sottoprogramma.

Il primo sottoprogramma possiamo già tradurlo in istruzioni eseguibili. È opportuno tenere presente che a questo livello il problema da risolvere riguarda solamente l’acquisizione delle temperature rilevate. Il resto del programma, a questo livello, non esiste.

Acquisizione temperature

Inizio Per indice da 0 a 11 Ricevi temperatura rilevata Fine-perFine

Passando al dettaglio del secondo sottoprogramma lo si può pensare composto da una fase di inizializzazione dell’accumulatore della somma dei termini della serie e delle variabili che conterranno il massimo ed il minimo della serie stessa. La seconda fase è il calcolo vero e proprio. Anche qui il problema è limitato solo alla parte specificata.


50

Calcolo media e ricerca massimo e minimo

Inizio Inizializza Somma Valori Considera primo elemento serie come Massimo e Minimo Aggiorna Somma e cerca Massimo e Minimo Calcola MediaFine Aggiorna Somma e cerca Massimo, MinimoInizio Per indice da 1 a 11 Aggiorna Somma con elemento considerato Se elemento<Minimo Sostituisci elemento a Minimo Altrimenti Se elemento>Massimo Sostituisci elemento a Massimo Fine-se Fine-se Fine-perFine

Calcolo escursione termicaInizio Escursione = Massimo – MinimoFineIl quarto sottoprogramma, come il secondo, prevede una inizializzazione:Calcolo scostamento medioInizio Azzera Somma scostamenti Aggiorna Somma Calcola Media scostamentiFine Aggiorna Somma scostamentiInizio Per indice da 0 a 11 Se elemento>Media aritmetica Scostamento = elemento-Media Altrimenti Scostamento = Media-elemento Fine-se Aggiorna Somma scostamenti con scostamento Fine-perFine

Comunicazione risultatiInizio Comunica Media Comunica Escursione termica Comunica Scostamento medioFine

Il programma a questo punto è interamente svolto. Ogni sottoprogramma ha riguardato un solo aspetto dell’elaborazione: ciò rende la stesura del programma più semplice ed inoltre la manutenzione del programma stesso diventa più semplice. Ogni sottoprogramma diventa più semplice da controllare rispetto al programma nel suo complesso. Ciò porta ad alcuni indubbi vantaggi:

Il sottoprogramma è facilmente esportabile La manutenzione del programma è semplificata dal fatto che, facendo il sottoprogramma una sola elaborazione e,

avendo al suo interno tutto ciò che serve, se c’è un errore nella elaborazione questo è completamente isolato nel sottoprogramma stesso e, quindi, più facilmente rintracciabile.

Qualora si avesse necessità di modificare una parte del programma, ciò può avvenire facilmente: basta sostituire solamente il sottoprogramma che esegue l’elaborazione da modificare. Il resto del programma non viene


51

interessato dalla modifica effettuata. L’utilizzo di sottoprogrammi già pronti per la costruzione di un nuovo programma porta ad una metodologia di

sviluppo dei programmi che viene comunemente chiamata bottom-up poiché rappresenta un modo di procedere opposto a quello descritto fino ad ora. Si parte da sottoprogrammi già esistenti che vengono assemblati assieme a nuovi per costruire la nuova elaborazione.

ATTENZIONENon sempre la strategia di progettazione orientata alle funzioni è la migliore, anzi può portare alla definizione di moduli fortemente accoppiati. Anche in presenza di un’ottima coesione si può presentare un pessimo accoppiamento a causa di moduli che comunicano per mezzo di dati in comune. La minima modifica della rappresentazione di questi dati si ripercuote su tutti i moduli che devono essere quindi modificati. Per risolvere il problema dell’accoppiamento è necessario che le funzioni, cioè i moduli, interagiscano con una visione astratta dei dati. Una soluzione è l’utilizzo di tipi di dati astratti per rappresentare le varie categorie di dati

Un esempio in Javascript in tempo reale per il controllo dei sensori

Tradizionalmente voglio rilevare dati ogni 3 secondi i dati di una temperatura (in questo caso simulati dalla funzione fakeValues che usa valori random) e mostrarli a browser

<HTML>  <HEAD> <title>Realtime JavaScript Application</title>

<style>

</style>



</HEAD>

<BODY onload="init();"> <DIV id="app">

<CENTER> <H1>Realtime JavaScript Application</H1> <H2>Web Interface for Monitoring sensors</H2>

</CENTER>

<DIV class="text">Day: <span id="dayValue" style="width:1000px;"> Today</DIV><DIV class="text">Field Temperature: <span id="tempValue" style="width:1000px;"> No sensor data available.</DIV><DIV class="text">Amount of Sunlight: <span id="sunValue"> No sensor data available.</DIV>

</DIV> </BODY> </HTML>

Strategia di progetto orientata agli oggetti La tecnica di progettazione basata sulle decisioni è stata individuata da Parnas nel 1972. Queste idee sono state integrate nella progettazione orientata agli oggetti che porta a moduli di altissima coesione e debolissimo accoppiamento

NOTA Objective-C is the primary programming language you use when writing software for OS X and iOS. It’s a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime. Objective-C inherits the syntax, primitive types, and flow control statements of C and adds syntax for defining classes and methods. (https://developer.apple.com/ )


53

#import "XYZPerson.h"@implementation XYZPerson- (void)sayHello { NSLog(@"Hello, World!");}@end

L’idea consiste nel progettare un sistema come un insieme di oggetti interagenti. Ogni oggetto è costituito da: uno stato cioè una rappresentazione interna nascosta agli altri oggetti (information hiding) un insieme di funzionalità che gli altri oggetti possono utilizzare in modo controllato, per accedere e modificare

informazioni contenute nell’oggetto (e cioè il suo stato).

Un oggetto è quindi noto all’esterno come un insieme di funzionalità, le funzioni di interfaccia costituiscono il protocollodell’oggetto.

In particolare: I dettagli realizzativi di un oggetto non sono noti all’esterno (information hiding) Gli oggetti modellano i concetti del dominio, sono i moduli del software che viene costruito, le funzioni sono

preposte alla manipolazione degli oggetti ed alla loro comunicazione Gli oggetti comunicano mediante message passing (cioè logicamente) sono entità attive e la chiamata di un modulo è vista come la richiesta ad un oggetto di eseguire una sua

funzionalità

Il sistema risultante è altamente modificabile. L’obiettivo della progettazione orientata agli oggetti è di progettare il sistema in sottosistemi mutuamente indipendenti checomunicano per mezzo di interfacce astratte.

Differenze e analogie tra approccio funzionale e ad oggetti

approccio funzionale Approccio orientato agli oggetti

Nell’approccio funzionale le decisioni sulla rappresentazione dei dati

e la condivisione di informazioni sullo stato devono essere prese prima.

Questo tende ad aumentare l’accoppiamento del sistema e quindi a ridurre la modificabilità dello stesso

Un oggetto è noto all’esterno come entità attive e la chiamata di un modulo è vista come la richiesta ad un oggetto di eseguireuna sua funzionalità

Buona coesione Buona coesione

coesione intorno alle funzionalità La progettazione ad oggetti porta a coesione attorno ad entità

Approccio classico:http://lia.disi.unibo.it/Courses/FondB0102-TLC/materiale/01-00esempi.pdf

main() {

… int cont;

cont++;

cont--;

if (cont == MAX) {….}

cont = cont*cont; /* puó avere senso per un intero manon ha alcun senso per una entità contatore */}

DATI (Attributi che caratterizzano un contatore):

int valore_cont;

OPERAZIONI (quelle permesse su un tipo di dato “contatore”)

void inc(){ valore_cont++;}

void dec(){ valore_cont--;};

int getValue(){ return valore_cont;};

Vorremmo Poter Fare:

main()


54

PROBLEMI

dov'è l'entità, il tipo di dato astratto,contatore?

dove sono le operazioni ammesse sui dati ditipo contatore?

possiamo fare cose NON SENSATE sul contatore stiamo usando le mosse elementari della

macchina C (integer e operatori di incremento),non stiamo usando delle categorie concettualidi tipo contatore! non possiamo ri-usare ilconcetto di contatore

{

Contatore cont; /* definisco un Contatore*/

/* NEL LINGUAGGIO A OGGETTI SI DICE "ISTANZIARE" */

Contatore cont2; /* ne istanzio un'altro */

cont.inc(); /* invoco delle operazioni sul contatore */

cont.dec();

cont2.dec() /* le stesse operazioni le posso invocare

chiedendole all'altro contatore: sono dello stesso tipo,

ma ovviamente avranno attributi specifici diversi!*/

if(cont.getValue() > MAX) {….}

cont++; /* IL COMPILATORE DA’ ERRORE: NON E' UN INTERO */

cont.valore_cont=cont*345;

cont.valore_cont++ /* ERRATE ENTRAMBE: il dato valore_cont è accessibile solotramite le operazioni di cont */

}

Approccio Classico: Vorremmo Poter Fare:

typedef struct Studente {char nome[20];char cognome[20];int matricola;int num_esami_dati;struct esami[29] {char nome[20]; int voto;}}void nuovo_esame_dato(Studente s, char*nome_esame, intvoto_preso){...}/* e altre funzioni varie…..*/

main(){ Studenti s1, s2; s1.nome = "pippo"; s2.cognome = "rossi";/* NON BELLO: COSI’ ACCEDO AI DATIINTERNI DI STUDENTE*/}

DATI:char nome[20];char cognome[20];int matricola;Cont num_esami_dati;struct esami sostenuti {char * nome; int voto};

OPERAZIONI:void nuovo_esame_dato(char *nome_esame, int voto_preso);Int calcola_media(void);void iscrivi_anno_successivo();

main(){Studenti s1(”Rebecca Montanari"), s2("Donald", "Duck");s1.nuovo_esame(s1, ”FondamentiInformatica", 28);}

GROSSO CAMBIAMENTO DI PARADIGMA:NON si richiede a funzioni di operare su datinuovo_esame(s1, "Sistemi Operativi", 28);

MA si richiede alle entità di eseguire delle funzionis1.nuovo_esame(s1,"Sistemi Operativi", 28);

La migliore strategia di progettazione?

Si possono vedere come due strategie complementari piuttosto che alternative

Nella progettazione possiamo individuare fasi temporalmente consequenziali:

(funzionalità) Inizialmente il sistema da realizzare si presenta logicamente costruito da un insieme di sottosistemi cherealizzano delle funzionalità

(oggetti) Ogni sottosistema può essere modellato come un oggetto al quale si associano le relative funzionalità: èopportuno usare una strategia orientata agli oggetti

(funzionalità) In un successivo momento si determina per certe operazioni un preciso flusso di dati che consente dideterminare una sequenza di operazioni: è opportuno allora usare una strategia funzionale

(oggetti) Si entra poi nel dettaglio della struttura dei moduli, vengono prese decisioni che è opportuno mantenerenascoste all’esterno dei moduli vengono presentate solamente le funzionalità richieste: è opportuno ritornare di nuovoad una strategia orientata agli oggetti


55

Il progetto viene visto e rivisto più volte

Un esempio: le classi in Java

I linguaggi ad oggetti includono sempre un tipo di modulo chiamato classe, che è uno schema dichiarativo che definisce tipi di oggetti La dichiarazione di classe incapsula la definizione dei campi e dei metodi degli oggetti creabili come istanza della classeLa classe (in UML) Definisce:

Uno stato persistente Un comportamento

La classe ha : Nome – Attributi – Operazioni

Ha una rappresentazione grafica in forma di un rettangolo diviso in tre parti, ad esempio:

Terminologia Classe: Nome collettivo (dichiarazione di tipo) di tutti gli oggetti che hanno gli stessi metodi e variabili di istanza. Oggetto: Entità strutturata (codice, dati) e con stato la cui struttura e stato è invisibile all’esterno dell’oggetto. Stato: Lo stato di un oggetto si accede e manipola mediante messaggi che invocano metodi Variabili di istanza: Variabili contenute nell’oggetto che rappresentano il suo stato interno Messaggio: Richiesta ad un oggetto di invocazione di uno dei suoi metodi Metodo: Azione che accede o manipola lo stato interno del’oggetto (di solito le variabili di istanza).

L’implementazione di tale azione è nascosta al cliente che spedisce messaggi all’oggetto


56

Che cos’è la progettazione OO? Orientato agli oggetti: Decomposizione di un sistema mediante astrazioni di oggetto Diversa dalla decomposizione funzionale/procedurale

Cfr.

Il Pattern MVCTalvolta l’uso del semplice linguaggio allo stato puro, specie per siti di una certa rilevanza, risulta un po’ limitante. In questi casi è utile separare il codice dai dati e dalla presentazione.Il Model-View-Controller (MVC) è un pattern (un modello di progettazione) basato sulla separazione dei contenuti dalla rappresentazione e definisce tre meta-componenti che definiscono l’applicazione:

il model fornisce i componenti per accedere ai dati utili all'applicazione, ad esempio un database; il view , cioè i componenti per visualizzare i dati contenuti nel model e si occupa dell'interazione con utenti; il controller che riceve i comandi dell'utente (in genere attraverso il view) e gestisce la logica dell’applicazione

Nel contesto web i tre componenti si applicano al client (view), al serever web (controller) e alla persistenza di dati ,"”, (database).


57

ZENDZend Framework () è un per lo sviluppo di , scritto in linguaggio 5.Zend Framework è spesso associato a una 'libreria di componenti', perché ha molti oggetti e funzioni che è possibile utilizzare più o meno indipendente. Ma Zend Framework fornisce inoltre un avanzato Model-View-Controller (MVC):Model - Questa è la parte dell'applicazione che definisce l’accesso ai dati e ai databaseView - definisce ciò che viene presentato all'utente. La view ha il compito di formattare i dati da inviare al browser: qui è molto probabile trovare codice HTML.Controller - lega l'intero pattern insieme. Manipola i modelli, al fine di decidere quale visualizzare in base alle richieste dell'utente e ad altri fattori.

J2EE Un tipico esempio web di MVC definito con Java 2 Enterprise Editin (J2EE) usando servlet (Le servlet operano all'interno di un web (per esempio, ) per la creazione di pagine dinamiche)e pagine JSP (un testo, scritto con una specifica, che rappresenta una . Elaborando la pagina JSP, il motore JSP produce dinamicamente la pagina HTML finale che verrà presentata all'utente. Nel contesto della piattaforma Java, la tecnologia JSPè correlata con quella dei ):

servlet per i controller pagine JSP per le viste oggetti JavaBeans per la persistenza dei dati

Uno dei maggiori framework è Struts (http://struts.apache.org/), della Apache Software Foundation. Struts mette a disposizione una certa tipologia di classi Action che sono dei JavaBeans (classi scritte in Java, usate per incapsulare molti oggetti in un singolo oggetto: il bean) con una particolare interfaccia che supporta il passaggio dei parametri tramite Request, Response. Il concetto è che Struts centralizza il controllo con un’unica servlet che distribuisce le richieste a piu’ Action specializzate per particolari operazioni.


58

L’interfaccia utente“Utente - Di lui si dice spesso che non sa quello che vuole. Sarà anche vero, ma una cosa è certa: l'utente sa benissimoquello che non vuole.”

L’interfaccia utente agisce come interfaccia tra utente e sistema e ha due responsabilità fondamentali: Mostrare le informazioni agli utenti Inoltrare le informazioni in input e avviare le elaborazioni

Occorre ricordare che : Le persone hanno memoria a breve termine limitata; Le persone possono sbagliare; Le persone differiscono notevolmente tra loro per abilità fisiche e attitudini.

Regole d'oro dell'Interfaccia Utente

Esistono 3 regole d’oro che devono guidare nella progettazione dell’interfaccia utente (Mandel, 1997)

1. Lasciare che il controllo sia nelle mani dell’utente2. Limitare la necessità per l’utente di fare ricorso alla propria memoria3. Utilizzare un’interfaccia uniforme per tutta l’applicazione

Queste 3 regole generali si traducono in un insieme di principi che è bene rispettare quando si definisce un’iterfaccia utente. Quindi:

L’interfaccia deve utilizzare termini e concetti che siano familiari agli utenti, piuttosto che ai programmatori. Il sistema deve essere in grado di ripristinarsi facilmente in seguito ad un errore dell’utente. Aiuti, guide in linea, suggerimenti devono aiutare l’utente nell’utilizzo migliore dell’interfaccia. L’interfaccia deve potersi presentare in maniera differenziata rispetto alle esigenze e alle preferenze dei diversi utenti

Vari tipi: riga di comando menu form toolbox finestre di dialogo con pulsanti

Regola fondamentale (Douglas Adams)Un errore comune che molti commettono quando tentano di progettare qualcosa di completamente fool proof” è quello di sottovalutare l'ingegnosità degli utenti

Definire la modalità di interazione in modo da non costringere l’utente ad azioni inutili o indesiderate es. prevedere la possibiità di modifica del testo anche in fase di correzione ortografica

Offrire sempre un’interazione flessibile: l’input deve essere possibile attraverso più canali (tastiera, menù) Ogni azione deve poter essere interrotta o annullata Nascondere all’utente i dettagli tecnici Prevedere modalità d’uso abbreviate (macro o short-cut) per utenti esperti Usare metafore che permettano la manipolazione diretta degli oggetti visibili

Processo di Progettazione dell’Interfaccia

Il processo che porta al progetto di interfaccia segue preferibilmente un andamento spiraliforme (analogo al modello di sviluppo a spirale) basato su 4 fasi:


59

1. Analisi e modellazione degli utenti, dell’ambiente e delle operazioni2. Progetto dell’interfaccia3. Implementazione dell’interfaccia4. Validazione dell’interfaccia

«La brevità consiste nel dire molte cose in poche parole e, se fosse possibile, a far pensare più di quanto si dica» (Roukhomovsky, 2001)


60

Come si realizza un progetto software?Il lavoro di ingegnerizzazione del software viene normalmente organizzato in progetti

In generale non possiamo produrre software nella maniera più immediata Possono richiedere l’applicazione di più strumenti (linguaggi di programmazione, algoritmi) Possono coinvolgere più persone (sviluppatori, committenti e utenti) Sistema software di piccole dimensioni: team di sviluppo unico con tre/quattro sviluppatori Sistema software di dimensioni grandi: il lavoro viene suddiviso in molti progetti piccoli

I progetti prevedono: Modifica di software esistente Sviluppo di un sistema da zero Sistema nuovo costruito con componenti già esistenti

Un progetto software è:• Temporaneo: Ogni progetto ha un inizio e una fine ben precisa (obiettivo raggiunto o irraggiungibile)

– non significa che dura poco infatti molti progetti durano diversi anni• Unico: Ogni progetto riguarda qualcosa che non è mai stata fatta prima ed è pertanto unica

– un progetto differisce da un altro per il tipo di oggetto sviluppato, per gli strumenti usati, per le persone coinvolte o soltanto per le date

Il team di sviluppo di un progetto software“Se vuoi migliorare in modo incrementale, sii competitivo; se vuoi migliorare in modo esponenziale sii cooperativo.”Autore ignoto

Obiettivi

- Coinvolgervi nello sviluppo di un progetto software- mettere a frutto le conoscenze che avete acquisito (programmazione, algoritmi, ingegneria del software, …)- applicare un processo per la gestione e lo sviluppo del progetto analogo a quelli usati nel mondo reale

Come?

Lavorerete in team di 2/3 persone un leader uno o più analisti due o più programmatori

Sarete voi a scegliere il ruolo più adatto alle vostre capacità e alla vostra indole. Mi comunicherete la formazione del vostro gruppo ed eventuali modifiche.


61

I Leader

• Problem solving:– determinare i fattori tecnici e organizzativi più importanti– strutturare sistematicamente una soluzione– motivare gli sviluppatori

• Identità manageriale:– assumersi la responsabilità del progetto– coordinazione del resto del team

• Incentivazione:– ricompensare lo spirito di iniziativa– saper rischiare

• Influenza e spirito di gruppo:– Mantenere il controllo nelle situazioni critiche– relazionarsi bene coi colleghi

Il team

• Staff tecnico auto-organizzato• Parola d’ordine: cooperazione

Criteri di valutazione• Qualità del progetto sviluppato• Coesione del gruppo

EsempiSviluppo di:• Un compilatore, un editor, un sistema operativo• Un applicativo web• L’implementazione di un algoritmo di ordinamento• Un dimostratore automatico• …Progetti software/ingegneria software

Esempio: programma di elaborazione testi• Stadio 1: funzioni base relative alla gestione dei file, al trattamento del testo e alla produzione di documenti• Stadio 2: funzioni più raffinate di trattamento del testo e di produzione dei documenti• Stadio 3: controlli ortografici e grammaticali• Stadio 4: funzioni avanzate di impaginazioneIl modello incrementale 3


62

Valutazione del Progetto La valutazione passa per un test di utilizzo dell’interfaccia da parte di un utente

Informale: un utente usa il sistema e fa un report Formale: gruppi di utenti utilizzano il sistema e vengono utilizzati metodi statisitici per valutare le reazioni

“NO PROBLEM è il metodo che ha fatto la fortuna di molte aziende medio-piccole del nordest.”


63

Soluzioni per la progettazione

UMLUML (Unified Modeling Language) è un linguaggio di modellazione, cioè una notazione anche grafica usata per esprimere le caratteristiche di un progetto, nell’ambito della programmazione ad oggetti. http://www.cs.unibo.it/gabbri/MaterialeCorsi/1.introUML.favini.pd f Tools : https://creately.com/app/?tempID=gc7qvpsj1&login_type=demo , https://www.youtube.com/watch?v=mxFt7j_louM

Si tratta di un linguaggio di modellazione usato per capire e descrivere le caratteristiche di un nuovo sistema o di uno esistente . UML è un linguaggio semiformale e grafico (basato su diagrammi) per:

specificare visualizzare realizzare modificare documentare

gli artefatti di un sistema (solitamente un sistema software).

Esso cerca di fornire una soluzione completa alla progettazione di un sistema, sia da un punto di vista statico che dinamico.

UML è il successore di una serie di metodologie di analisi e progettazione orientate agli oggetti. E’ molto vasto! Il processo proposto da UML consiste in una serie di “consigli” riguardanti i passi da intraprendere per produrre il

progetto stesso. Il modello UML tiene conto dei diversi aspetti funzionali, temporali e dei dati. Il modello presenta varie “viste” che descrivono i diversi comportamenti della realtà. Ogni vista è rappresentata con un

diagramma grafico e testuale insiemeUn esempio

Viste diverse del Duomo di Milano

Ricordiamo che UML include sia l’analisi che la progettazione orientata agli oggetti :- analisi: capire cosa deve fare il sistema, senza occuparsi dei dettagli implementativi- progettazione: capire come il sistema raggiunge il suo scopo, come viene implementato

Tipi di diagrammi UMLEsistono due grandi famiglie di diagrammi che descrivono aspetti diversi del sistema: aspetti statici

o diagramma di classi e oggetti


http://www.cs.unibo.it/gabbri/MaterialeCorsi/1.introUML.favini.pdf

http://www.cs.unibo.it/gabbri/MaterialeCorsi/1.introUML.favini.pdf

64

Class Diagram: è il diagramma di tutte le classi che lo sviluppatore dovrà creare e utilizzare Object Diagram: è il diagramma dell’istanza dell’oggetto della classe

o casi d’uso o Use Case Diagram: è una rappresentazione del comportamento del sistema aspetti dinamici

o diagrammi di sequenza o Sequence Diagram: è la rappresentazione di come interagiscono i vari oggetti nell’arco temporale

o diagrammi di stato o State Diagram: viene usato per monitorare il cambiamento di stato di un oggetto nell’arco temporale.

o diagrammi di attività o Activity Diagram: è molto simile ad un diagrammi di flusso e focalizza cosa accade passo dopo passo alle elaborazioni che avvengono nel sistema in funzione dei suoi cambi di stato

o Diagrammi dei Componenti o Deployment Diagram: rappresentazione dei vari componenti hardware e di come interagiscono con loro.

Diagrammi relativi agli aspetti statici di un sistema

http://www.ba.infn.it/~regano/tesi/tracker_model_file/UML.htmlDiagrammi di Classe, degli Oggetti (Class Diagram: è il diagramma di tutte le classi che lo sviluppatore dovrà creare e utilizzare, Object Diagram: è il diagramma dell’istanza dell’oggetto della classe)

Descrive la scomposizione in classi e le relazioni tra esse. Inoltre mostra una rappresentazione delle istanze delle classi, cioè gli oggetti

Partendo dalle specifiche del sistema si ricavano le classi che lo possono caratterizzare, descrivendoil tipo degli oggetti che compongono il sistema e le relazioni statiche esistono tra loro.

La principale relazione statica è l’Associazione. Una associazione rappresenta una relazione tra le istanze di due classi Es: Uno studente frequenta più corsi, un corso frequentato da più studenti

Es: Un Ordine deve venire da un singolo Cliente, e che un Cliente può fare più Ordini nello stesso tempo

I diagrammi delle classi mostrano anche gli attributi e le operazioni di una classe, e lerestrizioni che si applicano al modo con cui gli oggetti sono collegati tra loro.


http://www.ba.infn.it/~regano/tesi/tracker_model_file/UML.html

65

Concetto intuitivo: l'attributo “nome” della classe. Cliente indica che i clienti hanno un nomeGli attributi individuano lo stato interno degli oggetti di una data classe

Le operazioni rappresentano le computazioni che una classe sa come effettuare. Possono riportare all'esterno informazionisullo stato degli Oggetti. Possono modificare lo stato degli oggetti

Una classe UML è rappresentata da un rettangolo all’interno del quale sono presenti nome, attributi e comportamenti/operazioni (metodi)

Nota i simboli +-# indicano la visibilità, cioè se possono essere usati, o meno, da oggetti di altre classi.

Molteplicità delle AssociazioniGli estremi di una associazione possono essere etichettati con il nome del ruolo. Se non è indicato, il ruolo è il nome della classe

Il capo di una associazione ha una molteplicità. Indica quanti oggetti possono prendere parte alla relazione La molteplicità si può anche indicare con un intervallo m..n L'asterisco * rappresenta l'intervallo da 0 a infinito Nella pratica, le molteplicità più usate sono 1, * e 0..1


66

Diagrammi dei Casi d'uso (Use Case Diagram)E’ una rappresentazione del comportamento del sistema. Un caso d'uso è un insieme di azioni legate da un obiettivo comune per l'utente. I diagrammi di casi d'uso descrivono ad alto livello l'interazione tra il sistema e uno o più attori che richiedono un servizio.

Si tratta di un diagramma che esprime un comportamento, desiderato o offerto. Individua: chi o che cosa ha a che fare con il sistema (attore) che cosa l’attore può fare (caso d’uso). Modella i requisiti funzionali di un sistema che specificano cosa deve essere fatto. Sono indipendenti dalla tecnologia, dall’architettura, dalla piattaforma, dal linguaggio di programmazione. Si individuano prima gli attori e poi i casi d’uso!

Caso d’uso: specifica di una sequenza di azioni, incluse eventuali sequenze alternative e/o di errore che un sistema può eseguire interagendo con attori esterni.

Il nome (etichetta) dovrebbe essere basato su un verbo o su un sostantivo che esprime un avvenimento. Attore: un ruolo assunto da un utente o altra entità che interagisce col sistema nell’ambito di un caso d’uso. Non è

necessariamente umano: oggetto fisico, agente software, condizioni ambientali, etc. Associazione: collega gli attori ai casi d’uso.

Descrive le modalità di utilizzo del sistema, come è visto dall'utente (attore). Si rappresenta come un grafo che mostra le interazioni tra un utente e l’aspetto di un sistema. Risulta particolarmente utile durante la fase di specifica dei requisiti.Ad esempio:

Problema Si consideri un negozio che rende disponibile un catalogo liberamente consultabile on-line. Gli utenti registrati possono inviare un ordine di acquisto (comunicando i dati di pagamento), che viene memorizzato nel sistema e


67

trasferito al reparto ordini che lo evade. Si rappresenti il sistema con un diagramma dei casi d’uso.

Chi interagisce con il sistema (attori)? Clienti Amministratori del negozio online Reparto ordini

Cosa fanno (casi d’uso)? Il cliente si registra, consulta il catalogo ed effettua acquisti Il cliente sceglie il tipo di pagamento L’amministratore organizza il catalogo Il reparto ordini evade gli ordini

NOTA Una dipendenza tra casi d’uso; il caso incluso fa parte del comportamento di quello che lo include. Il caso d’uso che estende (client) specifica un incremento di comportamento a quello esteso (supplier).

Esempio BIblioteca

Diagrammi relativi agli aspetti dinamici di un sistema

Fino a qui abbiamo visto i diagrammi che rappresentano la struttura statica di una Architettura Software


68

Occorre però anche caratterizzarne il comportamento dinamico

Diagrammi di Sequenza Mostra l’ordinamento temporale dei messaggi scambiati tra gli elemrnti del sistema.

I Diagrammi di Sequenza sono utilizzati per mostrare quali comunicazioni vengono effettuate tra oggetti.

Diagrammi di StatoMostra gli stati che il sistema può assumere durante il suo ciclo di vita.

Descrivono l'evoluzione del sistema Sono costituiti da una serie di stati che descrivono delle attività, tra i quali ci si muove attraverso delle azioni Le azioni sono associate a cambiamenti di stato (transizioni), quindi sono considerate processi rapidi e non interrompibili Le attività sono associate a stati, possono prendere un lasso di tempo più lungo e possono essere interrotte da un evento


69

La sintassi generale di una etichetta associata ad una transizione è:

<Evento> [<Condizione>] / <Azione> “Esegui L'azione se si verifica l'evento, e la condizione è vera” La sintassi di una attività è più semplice: do/ <nome attività>

(uno strumento : https://www.smartdraw.com/state-diagram/)

Diagrammi di Attività Mostra le elaborazioni che internamente avvengono nel sistema in funzione dei suoi cambi di stato

Descrivono la sequenza delle attività e supportano un comportamento sia condizionale che paralleloDue costrutti fondamentali: Branch (diramazione) Merge (giunzione)


70

Diagrammi di Deployment Mostra come sono organizzate le componenti fisiche del sistema (file, librerie, eseguibili, moduli…)


71

Collaudo del softwareCollaudo del software (test) =Garantire che il sistema software sia privo di errori e difetti

Principi fondamentali Nelle prime fasi del processo di sviluppo software si passa da una visione astratta ad una implementazione concreta

(implementazione) A questo punto occorre iniziare una serie di casi di prova destinati a “demolire” il software realizzato Il collaudo è l'unico passo del processo software che si può considerare (dal punto di vista psicologico) distruttivo

anziché costruttivo Il collaudo deve infondere un senso di colpa? I collaudi sono distruttivi? Ovviamente no!

Nel collaudo ci domandiamo due cose: Scoprire i difetti presenti nel sistema (verifica) Stiamo costruendo il software in modo corretto?”

o Il software deve essere conforme alle specifiche; cioè, deve comportarsi esattamente come era previstoo Are we making the right product?

Verificare se il sistema è o meno utilizzabile in condizioni operative (validazione) o "Stiamo costruendo il giusto software?” Il software deve essere implementato in modo da soddisfare le attese

degli utenti e dei committenti“ Are we making the product right?

DefinizioniErrore (umano): incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell’uso di strumenti.

Difetto (fault o bug): manifestazione nel software di un errore umano, e causa del fallimento del sistema nell’eseguire la funzione richiesta.

Malfunzionamento (failure): incapacità del software di comportarsi secondo le aspettative o le specifiche; un malfunzionamento ha una natura dinamica: accade in un certo istante di tempo e può essere osservato solo mediante esecuzione.

Ad esempio:

Function RADDOPPIA ( )....read (x);y := x*x;write (y)...

ERRORE di editing/digitazioneDIFETTO (causato da un errore )=> “*” invece di “+”MALFUNZIONAMENTO => il valore visualizzato è errato. Possibile MALFUNZIONAMENTO in esecuzione… (può verificarsi o meno: dipende dall’input)

Relazione fra errore, difetto e malfunzionamento:


72

Standard IEEE per il TestingStandard IEEE 610.12-1990:(1) The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.IEEE Std.729-1983(2) The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software item.

Il testing ha lo scopo di scoprire i difetti di un programma. Un test dei difetti ha successo se porta il programma a comportarsi in maniera scorretta (cioè esibisce malfunzionamenti).Il testing può solo dimostrare la presenza dei difetti, ma non la loro assenza!! (Tesi di Dijkstra)Serve a:

Dimostrare al cliente e allo sviluppatore che il software soddisfa i suoi requisiti Si parla di Test di Convalida Verifica che il software si comporti adeguatamente usando un insieme di casi di test che riflette l’uso previsto Scoprire gli errori o difetti del software Si parla di Test dei Difett

Tale test ha successo se tutto funziona come ci si aspetta

Approccio usato: scoprire la presenza di difetti osservando i malfunzionamenti eseguire un programma al fine di scoprire un errore

Rivela la presenza di errori, NON la loro assenza Un caso di prova è valido se ha un'alta probabilità di scoprire un errore ancora ignoto Un test è riuscito se ha scoperto un errore prima ignoto (non il contrario!

Testing e debugging Testing e debugging sono due attività distinte

Testing: confermare la presenza di errori Debugging: localizzare e correggere tali errori

Strategie Problemi e LimitazioniStrategie:

Testing Top-down I test cominciano dalle componenti più astratte, e ci si muove via via verso le componenti di basso livello Testing Bottom-up I test cominciano dalle componenti più di basso livello, e ci si muove via via verso le componenti più astratte Alpha testing:uso del sistema da parte di utenti reali ma nell’ambiente di produzione e prima della immissione sul mercato.

Beta Testing:installazione ed uso del sistema in ambiente reale prima della immissione sul mercato.Tipicamente adottati dai produttori di packages per mercato di massa!

Problemi:

La correttezza di un programma è un problema indecidibile!non vi è garanzia che se alla n-esima prova un modulo od un sistema abbia risposto correttamente (ovvero non sono stati più riscontrati difetti), altrettanto possa fare alla (n+1)-esima;


73

Impossibilità di produrre tutte le possibili configurazioni di valori di input (test case) in corrispondenza di tutti i possibili stati interni di un sistema software.

Ulteriori ProblemiIn molti campi dell’ingegneria, il testing è semplificato dall’esistenza di proprietà di continuità. Se un ponte resiste ad un carico di 1000 tonnellate, allora resisterà anche a carichi più leggeri. Nel campo del software si ha a che fare con sistemi discreti, per i quali piccole variazioni nei valori d’ingresso possono portare a risultati scorretti. Il testing esaustivo (ideale) è condizione necessaria per poter valutare la correttezza di un programma a partire dal testing.

L’impossibilità del Testing Esaustivo!Se il ciclo fosse eseguito al più 20 volte, ci possono essere oltre 100.000 miliardi di possibili esecuzioni diverse!!!Se ogni test fosse elaborato in 1 ms, sarebbero necessari 3170 anni!!!


74

I sistemi e il loro controlloNessun uomo è un’isola,completo in sé stesso;ogni uomo è un pezzo del continente,una parte del tutto[John Donne, poeta (1572 – 1631) ]

Definizione di sistemaIn un sistema le parti “stanno insieme” non in modo generico o amorfo, ma sono “connesse tramite relazioni reciproche”. Cercano, cioè, di “raggiungere un obiettivo”.

dal dizionario… Sistema =>“Stare Insieme” dal greco Syn (insieme) – ìstemi (stare) “un insieme di entità connesse tra di loro tramite relazioni reciproche”, “insieme di parti o componenti connessi di cui si vuole studiarne le proprietà.”

Sistema (Dizionario della Lingua Italiana © 2010 Zanichelli editore)- insieme di elementi collegati: Esempio: un sistema di ingranaggi, il Sistema solare, costituito dal Sole e dai pianeti che gli orbitano attorno - insieme di organi vitali, che svolgono la stessa funzione: Esempio: il sistema nervoso - insieme di elementi geografici della stessa natura: Esempio: sistema montuoso; sistema fluviale - insieme di istituzioni pubbliche e di leggi che le regolano o organizzazione politica: Esempio: sistema legislativo; sistema economico, sistema repubblicano; sistema costituzionale - insieme di teorie, di princìpi; dottrina: Esempio: sistema filosofico - metodo seguito in un'attività: Esempio: un nuovo sistema di insegnamento, di coltivazione - metodo da seguire per cercare di vincere a un gioco: Esempio: ha giocato un sistema al totocalcio - l'insieme dei componenti di un elaboratore elettronico Esempio: sistema operativo, insieme di programmi che controlla la maggior parte delle funzioni di un computer e gestisce l'uso delle diverse risorse (memorie, periferiche, dati, programmi)

Cosi’, ad esempio, il sistema solare è costituito dal sole e dai pianeti che, trattenuti dalla forza di gravità, gli ruotano attorno. Un computer è costituito da una Unità Centrale che processa i dati e da memorie e periferiche che li contengono e gestiscono.

Un elemento essenziale e, talvolta, critico è la scelta del particolare gruppo di elementi a cui si dà il nome di sistema.La possibilità di scegliere i confini del sistema dà una certa elasticità: la cellula è spesso studiata come un sistema a séstante ma, talvolta, è comodo pensare a un sistema costituito da un insieme di cellule che formano un organo, ad


75

esempio il fegato o i polmoni.

Non sempre pero’ è facile distinguere un sistema da cio’ che non lo è.Un mucchio di sabbia è un sistema? E un sacchetto di biglie? E le molecole d’ aria in un pallone? E’ vero che esiste una relazione tra i granelli o biglie o le molecole eppure capiamo che ci manca ancora qualcosa affinchè possiamo definirli sistemi.Forse possiamo chiamarli aggregati caotici . Un sistema, al contrario, è caratterizzato da una organizzazione complessa delle sue parti le quali sono soggette ad alterazioni se escono o entrano nel sistema. Inoltre i sistemi sono “attivi” e posseggono un “comportamento” ed è proprio questo a cui, spesso, siamo interessati piu’ che al comportamento delle singole parti.Pensiamo quando telefoniamo o guidiamo una macchina. Quando parliamo al telefono non siamo interessati al modo in cui le informazioni passano nell’etere o nel filo. Quello che conta è la mia voce passi all’interlocutore remoto e che premendo un tasto la comunicazione possa interrompersi o riprendere.Possiamo perciò riassumere cosi’ la definizione di sistema:

un insieme di parti connesse in modo organizzato questo insieme è di interesse particolare i componenti del sistema si influenzano e subiscono alterazioni se ne escono l’insieme delle parti è attivo (anche non far nulla puo’ essere una attività!)

Studio dei sistemi e terminologiaLa Teoria dei Sistemi cerca di fornire gli strumenti logici e matematici per l’analisi e la comprensione dei sistemi servendosi spesso dell'associazione sistema-modello, e delle relazioni di causa-effetto .Capire i sistemi e le leggi che li regolano serve spesso a capire come poter esercitare un CONTROLLO su di essi. Soprattutto una conoscenza parziale o disorganica dei sistemi, in particolare di quelli complessi, puo’ causare conseguenze gravissime e danni addirittura irreversibili., come, ad esempio, ha dimostrato in questi anni l’uso delle risorse energetiche mondiali o la deforestazione.

confine del sistema

Ogni sistema deve avere dei limiti. Spesso è difficile! Basta pensare al sistema solare all’inclusione o meno di pianeti, asteroidi, comete …Nella realtà dobbiamo comunque porre dei limiti significativi che rappresentino cio’ che volgliamo indagare e nulla piu’.

scatola nera

Spesso non sappiamo come funziona un sistema al suo interno e neppure ci interessa. Altre volte pur conoscendo abbastanza bene le sue caratteristiche interne ci interessa solo agli effetti esterni.In agricoltura , ad esempio, al contadino , di norma, non interessa sapere i meccanismi biologici che determinano la nascitadegli steli di grano. Lui sa che se deposita un seme nel terreno al momento propizio e se lo innaffia e lo concima , da li’ nascerà una spiga e del grano . Quando io guido una macchina non sono tenuto a sapere il funzionamento dei pistoni e del motore. Io so che se faccio benzina e giro la chiave il motore si mette in moto e questo mi basta.

Quello che ci interessa è perciò conoscere il rapporto tra INGRESSO e USCITA, cioè il funzionamento quale risulta dall’esterno.Cioè siamo interessati alle conseguenze che avvengono nel sistema a fronte di cert ingressi che vengono forniti.Possiamo rappresentare un sistema come una scatola con ingressi (solitamente definiti dai segnali u) ed uscite (y). Lo stato del sistema è descritto da un insieme di variabili, dette appunto "di stato", solitamente indicate con la lettera x.

componenti e collegamenti

componenti = costituenti


76

collegamenti = connessioniproprietà (variabili) = i componenti hanno delle caratteristiche, una palla da biliardo possiede forma, massa, dimensione, colore …(aggettivi) le proprietà sono chiamate variabili e possono variare entro certi limiti. Alcune proprietà sono costanti (forma palla) , altre variano (posizione, velocità, colore ..)stato = fotografia, valore delle variabili in un particolare momento

sistema = insieme delle variabili che trattiamo

Comportamento del sistema

Una lampadina può essere accesa o spenta, cioè possiede due stati (2^1).Due lampadine hanno 4 stati (2^2):

Off Off Off On On Off On On

con 3 lampadine otto stati (2^3) e in generale, 2^n stati dove n è il numero degli elementi, in questo caso le lampadine.

In particolare, seguendo l’esempio proposto da Ross Ashby , una matrice costituita da 20 righe di lampadine per 20 colonne, possiede 400 lampadine. Se ogni lampadina può essere accesa o spenta abbiamo: 2^400 stati possibili, cioè 10^120 stati, cioè 1 seguito da 120 zeri!Nota: Si pensi che la terra era in uno stato gassoso circa 5x10^9 anni fa, cioè 1.6x10^17 secondi, cioè 1.6x10^26ns (1nanosecondo è pari a 10^-9 secondi), ancora molto lontani da 10^120, così come la stima del numero totale di atomi nell'universo visibile, pari a 1079 - 1085 .

Se poi consideriamo le possibili transizioni tra gli stati, cioè il numero di possibili modi in cui il sistema può passare da uno stato all’altro, il numero diventa enorme…Infatti , ad esempio, con due sole lampadine con quattro stati di partenza si possono avere 4 stati x 3transizioni (senza considerare la transizione su se stessa), cioè 12 transizioni possibili.Con 20, lampadine e 400 stati si possono avere (2^400)! (! È il simbolo di fattoriale).

E un monitor quanti pixel ha???

Le semplici considerazioni fatte possono dare almeno una vaga idea della complessità dei sistemi, anche di quelli piu’ semplici!

Classificazione dei sistemi

I sistemi si presentano in molteplici forme e grandezze. Alcuni sono limitati e seguono sempre la stessa traettoria, percorrendo sempre gli stessi stati come ad esempio il semaforo. Altri sono decisamente piu’ complessi e non sappiamo come potrebbero evolvere in futuro : un sistema economica, sociale o anche naturale.Quando però studiamo un sistema possiamo cercare di classificarlo facendolo rientrare in una certa categoria, esattamentecome i biologi classificano insetti o piante.Ad esempio distinguiamo i mammiferi dagli ovipari i vertebrati dagli invertebrati .Anche per i sistemi possiamo cercare di classificarli in funzione di alcune loro caratteristiche salienti.I sistemi possono essere classificati in base a :

La Natura


77

Il Tempo Proprietà delle variabili Proprietà delle relazioni

Se il criterio di classificazione è la natura del sistema dobbiamo considerarne l'origine e classificarli quindi in: Naturali --> esistenti in natura Artificiali --> realizzati dall'uomo Misti --> naturali, ma modificati dall'uomo (es. dighe)

Se il criterio di classificazione è il tempo dobbiamo distinguerlo in : Discreto --> puo’ esistere in uno e solo uno di un certo numero di stati separati. Il sistema deve saltare da uno stato

all’altro e non svanire in modo continuo. Ad ex. Passa da 1 a 2 , dal rosso al verde, un grafico a punti, etc. Continuo -->non hanno uno stato ben definito ma si muovono in modo impercettibile da uno stato all’altro. Ad ex. Un’

auto che si muove su una strada, un grafico continuo, i numeri reali etc.Se il criterio di classificazione si basa sulle proprietà delle variabili dobbiamo distinguerlo in :

Dinamico --> quando le variabili di stato cambiano valore nel tempo Statico --> quando le variabili di stato assumono sempre lo stesso valore Chiuso --> quando non interagisce con l'ambiente esterno , cioè non riceve nulla e non lascia uscire nulla. Ad es. un

sistema fisico di termodinamica con lo studio delle variabili di stato di un gas perfetto . Questi sistemi come si puo’ ben intuire sono chiusi solo in teoria perché non sono mai perfettamente isolati dal mondo esterno, Tuttavia se questi scambi sono talmente piccoli da essere ignorati possiamo egualmente considerarli chiusi!

Aperto --> quando interagisce con l'ambiente esterno: essi assumono materiale, energia, informazione dall’esterno e possono ritrasmettere tutto cio’ all’esterno. I sistemi biologici sono sistemi aperti. Un calcolatore è un sistema aperto. Una rete, Internet sono sistemi aperti. Essi sono molto importanti perchè sono dotati di Ingressi e Uscite e possono reagire agli elementi esterni e possono anche autoregolarsi.

Se il criterio di classificazione si basa sulle proprietà delle relazioni dobbiamo distinguerlo in : Deterministico --> quando ad una certa sollecitazione risponde con una sola e univoca risposta . Si pensi al semaforo in

cui la sequenza degli stati è del tutto decisa in anticipo e la traettoria è sempre la medesima nel tempo. Probabilistico o Stocastico --> quando ad una stessa sollecitazione può rispondere in diversi modi. Pensiamo a una

roulette, Facendola ruotare ripetutamente si ottengono risultati apparentemente imprevedibili. Cio’ pero’ non è del tutto vero . Infatti , come per il lancio dei dadi o di una moneta, siamo in grado di dire qualcosa sulla frequenza con cui appaiono i numeri. Ad esempio se lanciamo una moneta sappiamo che la probabilità che esca testa è del 50%, anche se non possiamo dire cosa uscirà al prossimo lancio.

Combinatorio --> quando l'uscita dipende solo dagli ingressi e non dallo stato interno. I sistemi combinatori sono detti anche “Sistemi senza memoria”.

Sequenziale --> quando l'uscita dipende sia dagli ingressi che dallo stato internoEsistono altre classificazioni, piu’ specifiche e dettagliate. Senza entrare in merito a queste classificazioni, riportiamo solo alcuni esempi.

Secondo il modo di operare e la loro natura fisica (C. Jones): Sistema manuale Sistema automatico Sistema uomo-macchina Sistema biologica Sistema fisico Sistema simbolico

…secondo un altro schema a livello crescente (K. Boulding ):

Sistema fisico Sistema dinamico Sistema cibernetico o autoregolato Sistema aperto o di automantenimento Sistema genetico di gruppo (botanico) Sistema animale Sistema umano Sistema sociale Sistema trascendentale

NOTA: Il modo di pensare sistemistico ha permesso di uscire dai ristretti campi specialistici delle varie scienze e di capire chenon sempre i sistemi reali ricadono necessariamente nelle divisioni delle varie scienze.


78

In particolare i sistemi che riguardano l’interazione uomo-macchina e, nello specifico, i sistemi di elaborazione che interagiscono con l’uomo escono dai confini rispettivamente dalla fisiologia-psicologia e ingegneria per costituire qualcosa di nuovo e diverso.La cibernetica , cioè la scienza del controllo e della comunicazione, valica i confini della singola disciplina ed entra nel terreno della interdisciplinarietà.

Automi a stati finiti - Uno strumento per lo studio di sistemi software:

Introduzione

Gli Automi a Stati Finiti sono usati in informatica da lungo tempo anche in sistemi particolarmente popolari, come il software peri videogiochi e la robotica. Utilizzare correttamente una macchina a stati può ridurre drasticamente il numero di test e semplificare il passaggio tra diverse modalità di esecuzione.

Molti sistemi software sono basati su eventi ( event-driven), il che significa che aspettano continuamente il verificarsi di situazioni esterne o interne, come un clic del mouse, la pressione di un pulsante, o l’arrivo di un pacchetto di dati. Dopo aver riconosciuto l'evento, tali sistemi reagiscono eseguendo azioni che possono includere la gestione di elementi hardware o l’attivazione di altre componenti software. Una volta completato la gestione dell’evento, il sistema torna ad attendere il prossimo evento. La risposta a un evento dipende dal tipo di evento e dallo stato interno del sistema e può generare un cambio di stato. Il modello eventi-azioni e transizioni di stato può essere rappresentato come una macchina a stati finiti (finite-state machine FSM).

Una Macchina a Stati Finiti (FSM) o Automa a Stati Finiti (o semplicemente una Macchina a Stati), descrive il modello di comportamento di un sistema composto da un numero finito di stati. Definisce, inoltre, le transizioni tra questi stati, e le azioni, inmodo simile a un grafico di flusso in cui si può controllare la logica di funzionamento.

UML conserva la forma generale dei diagrammi di stato tradizionali. I diagrammi di stato UML sono grafici diretti in cui i nodi indicano stati e connettori denotano transizioni di stato.

https://en.wikipedia.org/wiki/UML_state_machine

LEGENDAUn evento è qualcosa che influenza il sistema

Ogni automa a stati finiti ha uno stato che regola la reazione della macchina agli eventi.

Quando si genera un evento, l’automa risponde eseguendo azioni, come la modifica di una variabile, l'esecuzione di I/O, il richiamo di una funzione, la generazione di un altro evento o il cambio di stato

Il passaggio da uno stato a un altro viene chiamato transizione di stato e l'evento che lo causa viene chiamato evento di attivazione o semplicemente “trigger”

L’automa a stati finiti

L’Automa descrive il sistema in base al solo suo “funzionamento” senza alcun riferimento alla “cosa” (macchina o altro) e al modocon cui è realizzata.


https://en.wikipedia.org/wiki/UML_state_machine

79

Da un punto di vista formale l’Automa costituisce il modello di un Sistema Stazionario e Discreto. In pratica si considerano sistemi Stazionari che dipendono solo dallo stimolo ricevuto (Ingresso o Evento) e dallo Stato Interno, nel senso che lo stesso stimolo produce lo stesso effetto se lo stato interno è lo stesso, indipendentemente dall’istante in cui viene attivato, e sistemi Discreti con un numero finito di Stati e di valori di uscita.Il sistema si trova di volta in volta, in stati definiti e stabili che possono evolvere, in seguito ad ingressi che gli arrivano, verso altresituazioni stabili. Tali transizioni sono accompagnate, eventualmente, da Uscite o attività o Azioni che corrispondono alle operazioni richieste.

Un automa può essere descritto come un insieme A:

A = I, U, S, f, gdove:I è l’insieme degli ingressi;U è l’insieme delle uscite;S è l’insieme degli stati interni in cui può trovarsi;f è la funzione che fa passare da uno stato al successivo, St+1 = f (St, it);g è la funzione che determina il valore delle uscite, Ut = g (St, it).

In pratica la descrizione del processo di funzionamento del sistema si traduce in un Grafo a Stati e Transizioni, in cui i Nodi rappresentano gli stati e gli archi orientati le transizioni. Accanto ad esse ci sono gli Eventi (Ingressi) che provocano le Transizioni e le eventuali Uscite (Azioni) che vengono intraprese..

cfr.

In altre parole una FSM consiste in un sistema per il calcolo delle USCITE e dello STATO FUTURO a partire dagli INGRESSI e dallo STATO PRESENTE:

Uno stato rappresenta una situazione del sistema in quell’istante, ne dà cioè, la “fotografia” in quel momento. Nel diagramma mostrato (grafo orientato o , in gergo, pallogramma), abbiamo una macchina a stati con due stati: Acceso (Power on) e Spento (Power off). La macchina sarà sempre in uno di questi due Stati.

Un evento è uno stimolo esterno. In figura, abbiamo solo un tipo di evento, il clic sul pulsante. La macchina a stati risponderà a questo evento in entrambi gli stati.

Una transizione fa precipitare il sistema in un altro stato (ma potrebbe anche farlo rimanere nello stesso). Una transizione può avvenire solo in risposta a un evento.

Nel diagramma a stati mostrato sopra, l’ evento “Button clic”, nello stato "Power On" fa precipitare la macchina nello stato “Power off”. Lo stesso evento in “Power Off” fa cambiare lo stato macchina in “Power On”.

Implicita nel concetto di una transizione di stato è che una certa azione (cioè una esecuzione di codice) avrà luogo al momento della transizione. Nel nostro diagramma l’azione apre o chiude il circuito per il transito di energia elettrica.Gli automi si prestano molto bene nelle soluzioni di problemi informatici perché il diagramma a stati può essere rappresentato secondo una “tabella (o matrice) di transizione Stati/Eventi/Azioni” del tipo:

Stato / Evento Evento 1 Evento 2Stato 1 Stato2 / Azione 1 Stato1 / -Stato 2 Stato2 / Azione 2 Stato1 / Azione 3

Nel caso del nostro diagramma (esempio 0):Stato / Evento “button click”Power on “Power off” / “Open”


80

Power off “Power on” / “Close”

Tradurre questa tabella in codice risulta agevole e permette la creazione di un “motore” software capace di elaborare gli eventi e produrre le azioni corrispondenti.

Esempio 0. Il succedersi delle stagioni con gli effetti su un albero: Stati :

Inverno Primavera, Autunno, Estate,

con la relativa successione.Eventi :

il 21 marzo è l’evento che fa transitare da Inverno a Primavera, il 21 giugno da Primavera a Esate e cosi’ via…

Azioni: L’albero mette i fiori L’albero mette i frutti L’albero lascia cadere le foglie L’albero va “in letargo”

Non è difficile realizzare un grafo e la tabella delle transizioni.

Gli Automi possono essere usati per descrivere una grande varietà di situazioni come nel seguente esempio in cui l’Automa è usato come riconoscimento e accettatore di sequenze .Vediamo qualche esempio (alcuni esempi sono remixati da http://www.dmi.unict.it/~barba/Architetture.html/ESEMPI-ESERCIZI/eserciziCircuitiOld/SOLUZIONI/SoluzioniMilano/ESM3/esm3.html )

Esempio 1Progettare un controller per un distributore automatico che accetta tre tipi di monete di valore 5,10 e 25, rispettivamente. La merce viene erogata al raggiungimento del valore 20. Il distributore prevede un resto massimo di una moneta da 5 e di una da 10.

SOLUZIONE: Descriviamo l'automa a stati finiti. IN = {moneta da 5, moneta da 10, moneta da 25}OUT = {Nessuna merce, Nessuna merce rifiuta la moneta, Merce senza resto, Merce con resto 5, merce con resto 10, merce con resto 15}S = {A,B,C,D} dove:

A = Nessun credito B = Credito 5 C = Credito 10 D = Credito 15

La macchina a stati sara' la seguente:


http://www.dmi.unict.it/~barba/Architetture.html/ESEMPI-ESERCIZI/eserciziCircuitiOld/SOLUZIONI/SoluzioniMilano/ESM3/esm3.html

http://www.dmi.unict.it/~barba/Architetture.html/ESEMPI-ESERCIZI/eserciziCircuitiOld/SOLUZIONI/SoluzioniMilano/ESM3/esm3.html

81

Esempio 2 Fornire un automa a stati finiti che descriva il comportamento di un dispositivo che controlli un parcheggio con due posti macchina dotato di una sbarra al suo ingresso ed un'uscita (sempre aperta) diversa dall'ingresso. Ci sono anche delle cellule fotoelettriche all'ingresso ed all'uscita del parcheggio che permettono di sapere se una macchina ha attraversato un passaggio. Il dispositivo deve far abbassare la sbarra quando il parcheggio e' completo.

X = {entra, esce, niente, ee } Z = {Aperto, Chiuso} S = {Vuoto,1car,2car}Il diagramma degli stati è il seguente:

Esempio 3 In casa avete lo scaldabagno e la lavatrice, ma a causa di un impianto difettoso, non potete utilizzarli contemporaneamente. Fornire il diagramma degli stati di un automa a stati finiti che descriva il comportamento di un dispositivo che, opportunamente collegato agli interruttori di tali elettrodomestici, impedisca di utilizzarli entrambi nello stesso momento (se la lavatrice e' accesa allora accendere lo scaldabagno non ha alcun effetto e viceversa; non ha alcun effetto anche accendere contemporaneamente tutti e due).

L'insieme degli stati di ingresso sara' formato da coppie di informazioni yz che indicano se gli interruttori dello scaldabagno (y) o della lavatrice (z) sono stati premuti (1) o meno (0).Stati di ingresso : {00,01,10,11}L'insieme degli stati di uscita sara' formato da coppie di informazioni yz che indicano un segnale di accensione verso lo scaldabagno o la lavatrice.Stati di uscita : {00,01,10,11}


82

Esempio 5 Reralizzazione di una macchina a stati applicata mediante Assembly 8086

;I l motore di un cancello azionato elettricamente, viene messo in moto; per l'apertura tramite un interruttore a chiave.; Ad Apertura ultimata (fine corsa) viene chiuso e determina lo stato del motore.

;Definizione dei bit da testare:; Porta (o varin0): ; IN0 x x x x x x x x; | |; | chiave = 1 on, 0 off; fine corsa = 1 on, 0 off; Porta (o varout0) : ; OUT0 x x x x x x x x; |motore = 1 on, 0 off

;VINCOLI OGGETTIVI;1-una chiave mette in moto il motore del cancello;2-il motore è in funzione finchè non arriva all'interruttore di fine corsa

;VINCOLI SOGGETTIVI;1. al lancio del programma il cancello si presuppone che sia chiuso;2. il programma continua a funzionare in eterno

data segment ; add your data here! varin0 db 0 varout0 db 0ends

;DEFINEIN0 EQU 00hOUT0 EQU 01h

stack segment dw 128 dup(0)ends

code segmentstart:; set segment registers: mov ax, data mov ds, ax mov es, ax


83

MOFF: ;mov dx,IN0 ; ingressi e uscite (non usate in questo esempio) ;in al,dx mov al,varin0 ;Controllo sulla porta per la chiave and al,00000001B jz MOFFMON: or al, 00000001B ;Accensione motore mov varout0,al ;mov dx,OUT0 ;out dx,al

NonFine: ;mov dx,IN0 ;in al,dx mov al,varin0 and al,00000010B ;Aspetta lo switch del finecorsa cmp al, 00000010B jnz NonFine and al,11111110B ;spegni ;mov dx,OUT0 ;out dx,al mov varout0,al ;il motore si spegne e ritorna da capo jmp MOFF ;------------ mov ax, 4c00h ; exit to operating system. int 21h endsend start

Esempio 6 - Regolazione di un orologio digitale L'orologio è munito di tre pulsanti la cui pressione chiameremo P1, P2, P3 che servono per la regolazione delle ore, minuti,mese, giorno e per il passaggio dalla modalità del display in cui vengono mostrati ore e minuti alla modalità in cui vengono mostrati mese e giorno. Il tasto P1 serve per passare dallo stato in cui il display mostra ore-minuti agli stati di regolazione, iltasto P2 serve per incrementare il valore attualmente presente sul display (inc=incrementa), il tasto P3 è un tasto bistabile tra le modalità del display ore-minuti e mese-giorno. Ecco il grafo:

Esercizio n.0 (parzialmente risolto)La macchina accetta monete da 1 e 2 euroI = {nessuna moneta, 1e, 2e}• Fornisce il prodotto quando viene raggiunto l’importo di 5 euro (uscita a 1)


84

Convenzione: chiamiamo ogni stato della macchina con l’importo raggiunto

Esercizio n.0.1 Progettare un automa che distribuisce lattine di un solo tipo dopo che sono state introdotte due monete di un unico valore.Se il distributore è spento si "mangia" la moneta eventualmente introdotta.

Esercizio n.0.2 Progettare un automa che fornisce monete da 50c € in cambio di monete da 10c e da 20c di Euro. L'automa non fornisce inalcun modo resto.

Esercizio 12: ASCENSORE A DUE PIANI

Vogliamo qui descrivere il comportamento di un ascensore a due piani (piano terra e due piani) imitatamente a ciò che riguarda le chiamate dai pulsanti ai piani.

Esercizio 13 APERTURA/CHIUSURA CANCELLO AUTOMATICO http://www.edutecnica.it/pdf/sys/ea1.pdfUn dispositivo di controllo permette l'apertura di un cancello automatico quando vi giunge un se-gnale del comando portatile che corrisponde ad 1 "logico", altrimenti se giunge un segnale che corrisponde ad uno 0 "logico" esso si chiude.

Esercizio n.9 Enigma del lupo, del cavolo e della pecora. “Un barcarolo doveva trasportare sull' altra riva del fiume un lupo, una pecora e un cavolo, ma non trovò che una barca capace di portarne due alla volta (egli stesso più un altro). Gli era stato ordinato di non procurare alcun danno né agli animali né alla pianta (non può lasciare soli cavolo e pecora o pecora e lupo)”.( Tratto dalle Propositiones ad acuendos juvenes di Alcuino (*) ) Soluzione

Prima trasporta la pecora, lasciando a terra il lupo e il cavolfiore; poi torno indietro e porta sull'altra riva il lupo: giunto sull'altra riva, fa scendere il lupo, carica in barca la pecora e la riporto indietro. Faccio scendere dalla barca la pecora, prende il cavolfiore e lo porta sull'altra riva, quindi ritorna con la barca vuota ed infine trasporto la pecora.

Codifica come stringa Consideriamo le seguenti mosse:

Attraversa con lupo (l) Attraversa con pecora (p) Attraversa con cavolofiore (c) Attraversa solo il barcaiolo (s)

Stringa che identifica la soluzione: pslpcsp

Modellazione della soluzione


85

o Consideriamo le presenze sulle due sponde Est e Ovest come lo stato del sistema o Dobbiamo considerare anche la presenza del barcarolo sulle sponde (barcarolo simbolo b) o Le transizioni da uno stato all'altro sono gli spostamenti

(*) Soluzione originale di Alcuino ( Propositiones ad acuendos juvenes scritte, in latino, all’inizio del nono secolo da Alcuinomaestro di Carlomagno, )

“Un uomo doveva trasportare aldilà di un fiume un lupo, una capra e un cavolo e non potè trovare altra barca se non una che era in grado di portare soltanto due di essi. Gli era stato ordinato però di trasportare tutte queste cose di là senza alcundanno. Chi è in grado dica in che modo poté trasferirli indenni. “-“In modo analogo allora io dapprima porterei la capra e lascerei il lupo e il cavolo. Poi tornerei e trasferirei sull’altra riva il lupo e sbarcato questo e imbarcata di nuovo la capra ritornerei indietro, e lasciata la capra trasferirei di là il cavolo, e tornerei di nuovo indietro, e presa la capra la porterei sull’altra sponda. In questo modo, la traversata sarà tranquilla senza disastri che incombano”.

Esercizio 10 In casa avete un sistema di cellule fotoelettriche che invia un segnale che indica se siete in casa o no; inoltre indica anche se siete in bagno o no. Descrivere, attraverso un automa a stati finiti, il comportamento di un dispositivo che che invii un segnale di accensione o spegnimento alla segreteria telefonica. La segreteria va accesa se siete fuori casa e spenta se siete dentro. Inoltre quando siete in casa deve accendersi quando siete in bagno.

Esercizio n.5 Costruire la macchina a stati, sia in forma di grafo che di tabella di un distributore di bevanda: l’unica bevanda presente è il latte. La bevanda costa 20 centesimi e la macchina accetta solo 10 o 20 centesimi oltre al tasto “annulla” che funziona solo dopo l’inserimento di 10 centesimi. Al raggiungimento di 20 centesimi la macchina serve il latte automaticamente.Esercizio n.6 Costruire la macchina a stati, sia in forma di grafo che di tabella di un ascensore a 2 piani: l’ascensore ha i pulsanti Piano Terra (PT) e Piano 1 (P1). Le azioni sono “Sali” e “Scendi”.Esercizio n.7 Immaginiamo un incrocio tra due strade regolate tramite semafori.


86

Un semaforo può trovarsi in uno dei seguenti stati : S = {rosso, verde , giallo, lampeggiante} Supponiamo che il nostro sistema sia dotato di ingressi che condizionano l’evoluzione del sistema stesso. Supponiamo che l’insieme dei possibili valori di ingresso sia anch’esso finito e che il sistema, a determinati istanti di tempo, cambi di stato infunzione degli ingressi e dello stato corrente.

Automi riconoscitori

(cfr. http://terzablst.altervista.org/automiriconoscitori.html e http://www.sistemiautomatici.altervista.org/alterpages/files/automiriconoscitori.pdf )

Gli automi riconoscitori hanno il compito di controllare se una data sequenza di ingressi appartiene ad un insiemepredefinito di sequenze, stabilito a priori dal progettista in base a determinati scopi. In particolare gli automi riconoscitori di sequenza binaria controllano flussi di bit, cioè sequenze di ‘0’ e ‘1’, per intercettarequelle accettabili. Si tratta di automi particolari, aventi una o più entrate, ma sicuramente un’unica uscita. L’unica uscita è il segnale diriconoscimento che ci indicherà se quello che abbiamo in ingresso è qualcosa che viene riconosciuto oppure non vienericonosciuto. 0 = non riconosciuto1 = riconosciuto

Gli automi riconoscitori vengono utilizzati ad esempio dai software “traduttori”. I software “traduttori” sono moltoimportanti, infatti ci permettono di tradurre un programma scritto in un linguaggio di programmazione, vicino all’uomo, inun linguaggio binario vicino alla macchina. In ambito informatico però,esistono altri ambiti in cui vengono utilizzati gli automi riconoscitori: pensiamo ad esempio aquando accediamo all’elaboratore con l’inserimento di una password. Pensiamo ai robot in grado di riconoscere comandiforniti dall’ambiente esterno. Pensiamo anche alla trasmissione dei dati. Ad esempio:

Riconoscimento delle sequenze di sincronismo nelle trasmissioni ◦ I dati nei canali di comunicazione digitale viaggiano come sequenza di ‘0’ e ‘1’; le sequenze di sincronismo

sono configurazioni prefissate di bit, organizzate in modo da essere facilmente riconoscibili e da non interferire con i dati. Lo scopo dell’automa riconoscitore è appunto riconoscere tale sequenza e discriminarla dai dati utili

Controlli a distanza, telecomandi ◦ Anche in questo caso l’informazione è codificata in forma digitale, i vari comandi impartiti vengono codificati

ciascuno con una diversa sequenza di bit; l’automa riconoscitore riconosce le diverse sequenze distribuendo gli ordini all’organo a cui è destinato il comando.

Controllo dell’integrità di un’onda ◦ Ad esempio il segnale di clock: è una successione ordinata di ‘0’ e ‘1’ del tipo 01010101… l’automa in questo

caso deve controllare la sequenza ed emettere un segnale di allarme in caso si presenti un bit che altera la sequenza corretta.

Come lavorano gli automi riconoscitori Innanzitutto ricevono in ingresso un insieme di caratteri (uno alla volta).In ingresso possono avere: una stringa o un’infinità di caratteri. Per definizione la stringa (o parola) è un insieme finito di caratteri. Quando parlo di stringhe devo indicare l’alfabeto mediante il quale compongo la parola. Ad esempio aababbab e bbababb sono due stringhe sull’alfabeto composto dalle sole lettere {a,b}.Il grafo degli stati ci permette di capire se l’automa riconoscitore sta riconoscendo la stringa su un insieme finito o infinito di simboli numerici e/o alfanumerici. Due casi :

I°CASO: Se l’automa riconosce la stringa su un insieme finito presenta due nodi particolari:- un nodo iniziale (detto di START) dove non entra nessuna freccia, ma escono solo delle frecce - un nodo finale (detto di STOP) dove avviene l’esatto contrario: entrano tante frecce, ma non ne esce alcuna

II°CASO:Se invece l’automa riconosce la stringa su un insieme infinito di caratteri:c’è un solo nodo (nodo di START/STOP) che fa entrambe le funzioni; in esso entrano tante frecce ma ne esce una e una sola.


http://www.sistemiautomatici.altervista.org/alterpages/files/automiriconoscitori.pdf

http://terzablst.altervista.org/automiriconoscitori.html

87

Esempio 1.1 (I° caso) - Dato l’alfabeto costituito solo dalle lettere A,B e L ,riconoscere la parola ALBA.Alfabeto: {A, B, L} I = {stringa di valori} U = {0, 1} (LEGENDA: 0 = non riconosciuto, 1 = riconosciuto)

ESEMPI0 1.2 :

Dato l’alfabeto costituito solo dalle lettere M,O,V,A riconoscere la parola MOV.

Alfabeto: { M,O,V,A }OUT 0 = non riconosciuto, 1 = riconosciuto

S\E M O V

A

Si

SM/0

Serr/0

Serr/0

Serr/0

SM

Serr/0

0/SO

Serr/0

Serr/0

SO

Serr/0

Serr/0

SV/1

Serr/0

SVSerr/0

Serr/0

Serr/0

Serr/0

Serr

Serr/0

Serr/0

Serr/0

Serr/0


88

Esempio 2.1 (II° caso)- Automa che riconosce 1101 sulla linea seriale di collegamento tra due computer.I = {linea inserimento carattere} Valori IN = {1, 0}

U = {0, 1} LEGENDA: 0 = non riconosciuto 1 = riconosciuto

Esempio 2.2 riconosce la sequenza xxx e, solo in questo caso, emette 1 in uscita

xxx=011


89

xxx=100

xxx=010

Esempio 2.3 Generatore di parità

Esempio 2.4 Un sistema riceve sequenzialmente ma disordinatamente, rondelle, viti e dadi. La macchina deve ordinare la successione secondo la sequenza V-R-D. I pezzi non in ordine devono essere scartati. http://www.edutecnica.it/sistemi/automix/4.htm


http://www.edutecnica.it/sistemi/automix/4.htm

90

Esempio 2.5Quale linguaggio riconosce il seguente automa?

http://cabibbo.inf.uniroma3.it/it/pdf/it_03_automi_stati_finiti.pdf

Esempio 2.6 Riconoscere una stringa, sull’alfabeto (a,b), con numero pari di a e di b . Ad esempio aa Si, aabb SI, abb NO, ecc

(realizzato con var http://www.cs.usfca.edu/~galles/cs411/vas.jar

Esempio 2.7 Macchina che accetta tutte e sole le stringhe con un numero pari di zeri e un numero pari di uni


http://www.cs.usfca.edu/~galles/cs411/vas.jar

http://cabibbo.inf.uniroma3.it/it/pdf/it_03_automi_stati_finiti.pdf

91

Esempio 2.8

Esempio 2.9Contatore up/down Realizzare una macchina a stati di un contatore modulo 4 (da 0 a 3), la tabella delle transizioni ed il codice corrispondente. (http://www.issgreppi.gov.it) Diagramma degli stati


http://www.issgreppi.gov.it/corsi/claroline/backends/download.php?url=L0ZTTS9Fc2VyY2l6aS1tYWNjaGluZS1hLXN0YXRpLTEtc29sdXppb25pX3R1cmluZy5wZGY%3D&cidReset=true&cidReq=VIL_TEC_3TA_003

92

Esercizio n.1 Costruire la macchina a stati, sia in forma di grafo che di tabella di un riconoscitore: Vite,Dado e Vite,Rondella,Dado

Esercizio n.2 Costruire la macchina a stati, sia in forma di grafo che di tabella di un riconoscitore della sequenza 1101 che produce l’uscita 1 solo quando ultimata, altrimenti nessuna uscita.

Esercizio n.3 Costruire la macchina a stati, sia in forma di grafo che di tabella di un riconoscitore della parola ‘MIO’ che produce l’uscita 1 solo quando trovata, altrimenti nessuna uscita.

Esercizio n.4 (Generatore di parità) Costruire la macchina a stati, sia in forma di grafo che di tabella di un generatore di parità: data una sequenza di 0 e 1 in ingresso e dal simbolo terminale T, fare in modo che l’uscita finale sia1 o 0, rispettivamente se il numero di 1 rilevati sia dispari o pari.

Esercizio n.8 AUTOMI DETERMINISTICI SULL’ALFABETO E={a,b} Costruire gli automi finiti deterministici sull'alfabeto E={a,b} che accettano i seguenti linguaggi: 1. P: insieme delle parole che iniziano per ab e terminano per ba.2. Q: insieme delle parole che contengono almeno una a e almeno una b.3. R: insieme delle parole in cui ogni sottostringa aa è immediatamente seguita da almeno una b.4. S: insieme delle parole palindrome di lunghezza 2.5. T: insieme delle parole palindrome di lunghezza 4. 6. U: insieme delle parole palindrome.

Esercizio 11 Automa che riconosce identificatori e numeri Un identificatore è costituito da una lettera seguita da altre lettere o cifre. Un numero intero è una sequenza di cifre. Il seguente automa riconosce identificatori e numeri interi. Soluzione: Lo stato finale X è quello a cui si arriva se la stringa di ingresso è un identificatore. Lo stato Y corrisponde invece ai numeri interi .Lo stato finale X è quello a cui si arriva se la stringa di ingresso è un identificatore. Lo stato Y corrisponde invece ai numeri interi.

Esempio 2.10 http://www.feelinglinux.com/articles/automi.jsp

Toolshttp://www.jflap.org/ http://www.cs.usfca.edu/~galles/cs411/ NB var http://www.cs.usfca.edu/~galles/cs411/vas.jar

Whatsapp http://domainengineering.haifa.ac.il/seminar/Works/2016_InstantMessaging/WebFiles/wtsapp.html http://www.itistulliobuzzi.it/informatica/informatica/3h/problemi%20olimpici%202-12.pdf

Esempio di domande in verifica1. Quesiti per la valutazione delle conoscenze 1. Definire un sistema


http://www.itistulliobuzzi.it/informatica/informatica/3h/problemi%20olimpici%202-12.pdf

http://domainengineering.haifa.ac.il/seminar/Works/2016_InstantMessaging/WebFiles/wtsapp.html

http://www.cs.usfca.edu/~galles/cs411/vas.jar

http://www.cs.usfca.edu/~galles/cs411/

http://www.jflap.org/

http://www.feelinglinux.com/articles/automi.jsp

93

……………………………………………………………………………………………………………… ……………………………………………………………………………………………………………… ……………………………………………………………………………………………………………… ……………………………………………………………………………………………………………… 2.. Definire un automa …………………………………………………………………………………………………………… …………………………………………………………………………………………………………… …………………………………………………………………………………………………………… 3 Quali sono i modelli per rappresentare gli automi e quali le differenze? …………………………………………………………………………………………………………… …………………………………………………………………………………………………………… ……………………………………………………………………………………………………………4. DESCRIZIONE Una macchina riceve sequenzialmente ma disordinatamente rondelle ,viti e dadi. La macchina deve ordinare la successione secondo la sequenza vite-rondella-dado. Quali sono le variabili di ingresso? Quali valori possono assumere le variabili di ingresso? Quali sono le variabili di uscita? Quali valori possono assumere le variabili di uscita? Quanti e quali sono gli stati? Descrivi il diagramma degli stati. Descrivi la tabella funzione dello stato futuro e di trasformazione dell’uscita.


94

Il controllo dei sistemiPer far raggiungere a un sistema un certo obiettivo, dobbiamo controllarlo. Il controllo permette ad un sistema di raggiungere uno stato specificato. Per fare questo il sistema dovrà essere influenzato in modo che percorra una “traettoria” costituita da stati successivi, fino al raggiungimento dello stato finale.

Tre sono le cose necessarie per il controllo di un sistema: Un sistema per poter raggiungere l’obiettivo Lo stato di arrivo Un qualche mezzo per influenzare il comportamento del sistema

I “controlli” (o comandi) sono i mezzi che servono a intervenire sul sistema . Basti pensare al manubrio di una bici o al volante diun’automobile.Quando esercitiamo un controllo su un sistema, spesso, introduciamo qualcosa nel sistema agendo con segnali di Ingresso (o segnali di controllo).

Controllare un sistema significa, perciò, agire sui segnali di ingresso in modo da ottenere la risposta (o reazione) desidarata.

Il controllo dei sistemi può avvenire a anello aperto (circuito aperto, Open-loop) , senza alcun ritorno, oppure con una retroazione, a anello chiuso, (circuito chiuso, Closed-loop).

Controllo a Circuito Aperto

I sistemi di controllo ad anello aperto sono quelle in cui il controllore indica al sistema di fare qualcosa, ma non utilizza i risultati di tale azione per verificare i risultati o modificare gli ingressi per verificare il comportamento correttamente del sistema:

Ad esempio se giro la manopola del miscelatore della doccia in una certa posizione fissa, otterrò certamente un’uscita che dovrebbe essere quella di ottenere una temperatura confortevole dell’acqua.Purtroppo i valori variano la temperatura raramente è stabile: i parametri variano in funzione dell’inerzia termica di tubi, delle condizioni estrene, dalla percezioni che noi abbiamo in virtù del fatto che siamo più o meno accaldati, ecc.


95

Controllo a Circuito Chiuso con retroazione negativa

Il controllo a circuito chiuso (controllo retroazionato) testa continuamente le uscite del sistema e ne modifica gli ingressi in mododa mantenere il sistema nello stato desdierato. Il valore del segnale di uscita del sistema è riportata in ingresso per apportare i cambiamenti desiderati:

Nel caso del miscelatore d’acqua, la regolazione avviene tipicamente posizionado il miscelatore nella posizione prevista ma, a differenza, dell’anello aperto, la persona mette la mano sotto il getto dell’acqua e agisce sulla leva del miscelatore: sel’acqua è troppo calda fa entrare acqua ferssa e viceversa. In questo modo si modifical’ingresso in funzione dell’uscita e, ripetendo la provapiù volte, l’obiettivo viene raggiunto.

Lo chema sottostante mostra cosa avviene nel tempo: se la temperatura è troppo calda, girando la manopola sul freddo, la temperatura dell’acqua si abbassa. Se è troppo fredda si dovrà aumentre l’acqua calda. E’ lapersone che “chiude” con una retroazione negativa (feedback) il sistema variando l’ingresso in funzione della temperatura dell’acqua in uscita. Prima o poi il sistema va a regime , almeno se non si è troppo impazienti !

Quindi, per controllare la temperatura dell’acqua e ottenerla confortevole, devo: Impostare la temperatura, ruotando la manopola nella posizione prevista Confrontare la temperatura in uscita con quella desiderata

o SE la temperatura è quella desiderata non fare nulla e torna a controllareo Altrimenti manora il miscelatore per correggere l’errore, cioè la differenza tra l’uscita desiderata e quella

reale. Se l’acqua è troppo calda ruoto sul freddo, se è troppo fredda ruoto sul caldo.

NOTA Ruotando il miscelatore in modo da compensare le uscite, si attua una retroazione negativa il cui scopo è ridurre la differenza tra l’uscita voluta e quella riscontrata, ciò la retroazione negativa tende a ridurre l’errore

Formalmente lo schema si rappresenta così:


96

E’ come guidare una macchina con lo sterzo: se si gira troppo a sinistra occorre girare un po’ a destra e viceversa.Bisogna fare attenzione però, perché se si è troppo frettolosi l’oscillazione potrebbe non avere termine, o addirittura divergere.

Se , ora, sostituiamo la mano della persona sotto la doccia con un sensore di temperatura e il miscelatore manuale con un sistema controllato, ad esempio, da un micrprocessore si ottiene un sistema controllato automaticamente.Più in generale, la figura sottostante mostra il controllo di un impianto realizzato da un sitema microcontrollore che agisce su un attuatore per imporre i valori in uscita. Il valore di riferimento (setpoint) viene comparato con il valore proveniente dall’uscita dell’impianto:

Perché è così difficile regolare il sistema? Il fatto è che che ci vuole del tempo tra quando si dà un comando in ingresso e quando l’uscita segue il comando. Il tempo che passa tra il momento in cui si agisce sul controllo e il risultato che si ottiene in uscita si chiama ritardo.Se ad esempio consideriamo la carica di un condesatore possiamo farcene un’idea:

Fig. 90-2

La retroazione negativa è è usatissima nei sistemi di controllo ad esempio per un posizionamento di un motore o tutte le volte che voglio correggere degli errori. La retroazione positiva, a differenza di quella negativa, è tale da aumentare l’ingresso e rinforzare l’errore. Nel caso della doccia


97

significa che se la temperatura era già calkda la si farà divenatre ancora più calda e viceversa. Un esempio di retroazione positiva è quella che facciamo quando accendiamo un fiammifero o quando pedalo sempre più forte o quando prendo un bel voto (non sempre). (Quando uno studente entra al mattino a scuola attua una retroazione negativa, quando esce una positiva! :).

In altre parole:- la retroazione negativa

o contrasta le variazioni dell’uscita causate dai valori in ingrssoo il valore del segnale di retroazione va a sottrarsi al valore di riferimento per ottenere un segnale di

attuazione- la retroazione positiva

o rafforza le variazioni dell’uscitao il segnale di retroazione si somma a quello di riferimento

Un esempio di retroazione con operazionali:

Controllo PID Immaginiamo di fermarci a uno stop con una bici. Freaniamo esattamente sulla striscia dello stop? Come si comportiamo? E se dovessimo ormeggiare una barca che non ha freni ma solo il motore che conrolla la rotazione dell’elica nei due versi? Vediamo quest’ultimo caso.

Quello che si tende a fare è arrivare all’obiettivo dolcemente, come in fig.90-2.Per arrivare alla boa di ormeggio occorre valutare due fattori: la velocità della barca e la distanza dalla boa: tanto è maggiore la velocità, tanto più lontano è necessario applicare una spinta contraria. Quindi sono due le componenti che determinano la spinta della barca:

una forza che spinge verso la boa tanto meno quanto la distanza è minore (cioè proporzionale all’errore) una forza che spinga in verso contrario, proporzionale alla velocità (cioè alla derivata della distanza nel tempo)

della barca rispetto alla boa.Se le cose vanno bene la barca attrraccherà alla boa!Per migliorare il controllo, occorre a volte, integrare il controllo proporzionale e derivativo con un controllo integrale che tiene conto del residuodegli errori che vengono sommati: tanto più l’errore persiste, tanto più il valore dell’integrale (la somma dei valori) divenetrà grande!

In generale, il controllo Proporzionale-Integrale-Derivativo (Proportional-Integral-Derivative, PID), è un sistema di negativa largamente usato nei . (cfr. ()

Il PID regola l'uscita in base a tre azioni: azione proporzionale: il valore del segnale di errore azione integrale: i valori assunti nel passato dal segnale di errore. Il segnale di attuazione dipende dall’accumulo

dell’errore nel tempo azione derivativa: la velocità con cui varia il segnale di errore. Il segnale di attuazione dipende dalla velocità di

cambiamento dell’uscita

Possiamo esprimere così l’equazione che determina la legge di di controllo (Proporzionale, Integrale, Derivativo) dell’uscita :


98

Più precisamente, detto e il segnale di errore, l’uscita in funzione del tempo è:

Da un punto di vista del codice possiamo immaginare il controllo PID, attraverso semplificazioni ingegneristiche (dato che normalmente la funzione da controllare se fosse conosciuta matematicamente non sarebbe necessario controllarla dinamicamente). Come la somma di tre componenti per capire quanto manovrare l'output, in base all'errore calcolato volta per volta.

La parte proporzionale è direttamente proporzionale all'errore. La parte integrativa somma nel tempo gli errori volta per volta; questo riporta nel lungo periodo la variabile di

uscita sui binari corretti. Purtroppo questo non impedisce un'oscillazione una volta raggiunto il valore desiderato La parte derivativa limita le oscillazioni della variabile di output, rendendo le variazioni di "actual position" più

dolci. Questo pseudocodice funziona di per sé, ma c'è da valutare ogni quanto campionare e quindi eseguire questi calcoli, e soprattutto i valori delle 3 costanti K previous_error = 0 integral = 0 Do forever error = setpoint - measured_value integral = integral + error*dt derivative = (error - previous_error)/dt output = Kp*error + Ki*integral + Kd*derivative previous_error = error wait(dt) enddo


99

Nella figura un esempio ( ) di controllo PID applicato alla variabile y che va a regime (valore di setpoint = 1). Si noti che, quando la variabile da controllare si stabilizza sul valore di setpoint, le azioni proporzionale e derivativa sono nulle, mentre quella integrale è l’unica a rimanere attiva, garantendo errore nullo a regime.

Un caso di studio “ST@F - SmartThermost@Forecast” - 4IA (2015-16)

( )

L’analisi del sistema

Il sistema permette la “regolazione intelligente di un impianto di riscaldamento (invernale) e/o codizionamento (estivo) per ambienti di medie grandi dimensioni”. In particolare l’analisi fatta prende in considerazione gli ambienti scolastici che sono caratterizzati, oltre che da vasti spazi, anche da un’elevata percentuale di vetrate con una forte illuminazione naturale. Se da un parte ciò porta grandi benefici per la qualità della visione per gli studenti e contributo energetico (almeno in inverno), d’altra parte crea grossi problemi sia per la dispersione termica, sia, soprattutto, per l’effetto serra che ne deriva con conseguente difficoltà di regolazione del microclima che porta a unadiminuzione del comfort con ripercussioni negative sull’attenzione in classe e l’apprendimento.

Il progetto ha seguito tre fasi di sviluppo:- creazione di un modello sistemistico che tiene conto dei possibili ingressi e uscite applicate al “sistema edificio

scolastico”, in cui l’irraggiamento è considerato un “disturbo” - progettazione e realizzazione di un prototipo basato su microcontrollore (Nucleo ST) in grado di applicare un

algoritmo per la regolazione del microclima in funzione dei parametri (temperatura esterna ed interna, umidità, ventilazione, irraggiamento, situazione metereologica locale,…) che influenzano l’ambiente

- test del sistema applicato all’Istituto scolastico “Facchinetti”

La metodologia di sviluppo seguita si è basata su uno sviluppo evolutivo e incrementale: l’uso dei PROTOTIPI è stato determinante per rispondere ai cambiamenti in corso d’opera, non essendo, all’inizio, perfettamente chiari i requisiti ed essendovi incertezza sulle aspettative finali.I prototipi hanno il vantaggio di approssimare il sistema definitivo in modo incrementale cosa che, per noi, è stata di grande aiuto per due motivi: evidenziare gli errori grossolani fin dall’inizio, mostrare i risultati parziali al resto della classe e ai docenti (che in questo caso rappresentavano le istanze del cliente). Il capitolo “Conduzione del progetto” entra in merito al modo di condurre il progetto e ai tempi e modi di sviluppo-


100

Il modello

Uno schema tipico di riferimento, per la termoregolazione è quello retroazionato (ad anello chiuso): lo schema prevede la continua azione di controllo e regolazione sul segnale di ingresso da controllare per far in modo che l’uscita sia esattamente quella desiderata.Nel caso della temperatura, ad esempio, si ricorrere alla determinazione dell’ errore, definito come la differenza fra il valore di riferimeto voluto e quello effettivamente rilevato (fig.1).

La fig. 1 mostra il modello sistemistico ad anello chiuso.

Il problema è che, in ambienti come quelli da noi considerati si può far affidamento sulla temperatura interna: le aule e i laboratori NON sono dotati di termostato e, al massimo esiste un unico punto di rilevamento della temperatura interna. Il controllo, di conseguenza, è più difficile da gestire e, solo parzialmente retroazionato: la regolazione avviene basandosi su altri parametri indiretti come delle curve empiriche prestabilite. In ogni caso nel nostro modello dobbiamo anche pensare ai “disturbi”,come, ad esempio, l’irraggiamento che intervine tramite le grandi vetrate esposte ai quattro punti cardinali.

Il sistema deve poter tollerare questi disturbi in modo che l’uscita non venga alterata anche in loro presenza (fig.2).

Fig.2 i disturbi (nella fattispecie l’irraggiamento) devono essere tollerati e non devono influenzare il comportamento del sistema a regime che deve mantenere costante l’indice di benessere.

In particolare l’algoritmo di regolazione ha cercato di mantenere costante l’“Indice di comfort”, Ic, (un parametro collegato alla temperature e umidità percepita dalla persona interna all’ambiente ) al variare di temperatura esterna, interna, umidità e irraggiamento:

Ic= f( temperatura esterna, temperatura interna, umidità, pressione, ventilazione)

L’algoritmo deve, inoltre, avere come obiettivo, quello di regolare la temperatura anche in funzione delle previsioni metereologiche del luogo, in modo da ottimizzare l’accensione della caldaia ottenendo un risparmio energetico non indifferente. Si tratta di un elemento che caratterizza e distingue il nostro sistema di controllo. Il fatto di disporre delle previsioni metereologiche della zona in cui è presente l’impianto, costituisce l’elemento chiave. E’ proprio prevedendo se ci sarà irraggiamento solare, se la temperatura esterna raggiungerà un certo valore, se ci sarà vento o pioggia che sarà possibile agire sull’impianto in modo da effettuare un’accensione ritardata della caldaia o uno spegnimento anticipato, con tutti le conseguenze del caso: comfort migliorato e consumi ridotti drasticamente.

Il sistema

Alla luce di quanto stabilito nella fase di analisi, possiamo ipotizzare il modello completo del sistema (fig. 3) che comprende , oltre all’impianto da gestire, diversi altri blocchi che precisano la fig.1 e mostrano in dettaglio le funzioni di controllo e attuazione.


101

Fig 3. Lo schema a blocchi del sistema completo

Lo schema a blocchi propone una serie di elementi che caratterizzano e determinano il comportamento dell’impianto.In particolare:

● Setpoint:è il valore di riferimento (Ic) che si vuole ottenere e mantenere come output. ● Output: valore di Ic (di fatto, l’insieme delle variabili fisiche che lo costituiscono: temperature, umidità, ecc.)● Comparatore: Concettualmente “sottrae “ il valore effettivo di Ic, che torna in feedback, al valore del setpoint,

per ottenere l'errore. Nel nostro caso il valore di Ic è ricavato dai parametri ricavati dai sensori. ● Controller: Questo elemento elabora l’errore (utilizzando, nelle intenzioni, un algoritmo Proporzionale-

Integrale, PI) per produrre una corrispondente azione di controllo che viene implementata dal blocco Attuatore . Nota: Il comparatore e il controller sono di fatto integrati nel sistema microcontrollore in cui sono annegati gli algoritmi relativi al PI. Il microcontrollore piossiede come ingressi fisici i valori di temperatura e umidità che concorrono alla determinazione di Ic, insieme alle variabili relative alle previsioni meteo

● Attuatore: induce le azioni sull’impianto. Di fatto si agisce sulle caratteristiche fisiche dell’impianto (ad esempio accendendo e spegnando la caldaia o facendola lavorare diversamente) per mantenere Ic al valore desiderato. Nel nostro caso, il blocco di attuazione, comprende semplici relè, pilotati dalle uscite del microcontrollore, che agiscono sulla caldaia dell’impianto

● Disturbi: sono rappresentati da ingerenze esterne che agiscono sull’impianto. Nel nostro caso, l’elemento di disturbo principale è dovuto all’irraggiamento solare

NOTA: il modello matematico su cui si basa il controllo del sistema è così definito:

dove: T= temperatura internac= parametro che dipende dall’inerzia termica del sistema e determina il tempo con cui il sistema va a regime: il valore di c è stato stimato in circa 7*10^-4 sec^-1 , corrispondente a circa 2 ore di tempo necessario al sistema per portarsi a regimeu = corrisponde all’azione di controllo che viene implementata dall’ attuatorew = irraggiamentoTe = temperatura esterna

Nota Per il momento abbiamo impiegato un modello semplificato che tiene conto SOLO della dinamica della temperatura!

Il prototipo

Il regolatore è basato su microcontrollore (Nucleo ST) in grado di applicare un algoritmo per la regolazione del microclima in funzione dei parametri (temperatura esterna ed interna, umidità, ventilazione, irraggiamento, situazione metereologica locale,…)che influenzano l’ambiente.Precisamente:

IN= { temperatura esterna (TEX), temperatura interna (TIN), Umidità (UM), …} + collegamento seriale per ricezione da Internet dei parametri atmosfericiOUT={ ON/OFF caldaia (STR),…}

Nota: per semplicità di progetto sono state valorizzate, in questo contesto e nei codici che seguiranno, solo gli input TEX,TIN,UM e parametri atmosferici) e STR per l’output


102

Fig 4 il prototipo (gli input/output indicati con … potranno essere usati per sviluppi futuri). L’irraggiamento stesso potrebbe essere rilevato con un sensore e inserito tra gli ingressi)

La programmazione su Raspberryo per le caratteristiche di STM32 Nucleo Board si faccia riferimento al sito ufficiale:

Per quanto riguarda l’acquisizione dei parametri relativi alle previsioni meteo da Internet, si è dovuto optare per un collegamentocon il microcontrollore Raspberry PI che, tramite la rete Wi-Fi scolastica/aziendale (o tramite rete cellulare, come previsto nel progetto) può accedere a siti meteo e ottenere le previsioni locali. Il codice Pyton, mostrato sotto, dimostra un esempio di acquisizione dal sito api.forecast.io, su cui ci siamo basati.Il sito Web di riferimento:http://forecast.io/#/f/45.6124,8.9011

Fig. 41 il sito di riferimento con le coordinate dell’ISIS Facchinetti di Castellanza.

I dati sono formattati in JSON in questo modo:latitudelongitudetimezonecurrently (con le condizioni seguenti, minuto per minuto, ora per ora, ecc.)minutelyhourly


http://forecast.io/#/f/45.6124,8.9011

103

d ailyalerts

Lo stralcio di codice per gestire i dati è il seguente:import requestsimport json

api_url="https://api.forecast.io/forecast/%s/%f,%f"api_key="<your_api_key>"lat= 45.6124long=8.9011

query_url = api_url % (api_key, lat, long)r = requests.get(query_url)if r.status_code != 200: print "Error:", r.status_code

json_weather = r.json()

print "Tomorrow will be ",currentWeather = json_weather['currently']['icon']if "cloud" in currentWeather: print "Cloudy"elif "rain" in currentWeather: print "Rain"else: print "Clear"

Le figure sottostanti rappresentano una panoramica del sistema inserito nel modellino Lego per la simulazione di un’aula scolastica:


104

Il processo di controllo

Il processo di controllo dell’impianto è pensato secondo una modalità top-down e si articola in una serie di chiamate alle funzioni:

● inizializzazione delle variabili, in particolare il valore di riferimento di ic che servirà da confronto● rilevamento degli input, temperature e umidità● elaborazione dei dati , algoritmo per la determinazione del valore di ic e per l’attivazione delle uscite● attuazione delle uscite.

Il cicloIl pseudo-.codice mostrato sotto, fornisce lo scheletro del ciclo:

main(){init_variables(tex,tin,um,ic);

loop { //polling loop forever

read_forecast(forecast); // read XML from serial line in_temp(tex,tin,um) //read input ic = process_data (tex,tin,um); //calculate icout_op=strategy(ic); // in order to ic -> operate on outputout_plant(out_op);}

}

Le funzioniinit_variables(tex,tin,um,ic) {

…IC=set_ic(reference); //set ic to ref (IC)… }

read_forecast(forecast){

…read_sin(xml_file_fore); //read file from serial line

set_variables(currently,minutehourly, daily, alerts); //set var in rder to ic calc…}

ic = process_data (tex,tin,um){

…read_sin(xml_file_fore); //read file from serial line

set_variables(currently,minutehourly, daily, alerts); //set var in order to ic calc…

return (ic);}

strategy(ic){

…avvio(){ //funzione all’avvio del sistema che calcola lo

leggitemp(); //sbalzo di temperatura in 15 minuti con ONcaldaia(); //l’avviamento della caldaia attesa15min(); OFFcaldaia(); leggitemp(); calcolosbalzo(sbalzo);


105

}

gestione(sbalzo,orariodesiderato){ //funzione per la gestione del sistema leggitemp(); //che ricerca l’orario ottimale per ricercaN(); //avviare la caldaia e ottenere if(ricercaOra()){ //una temperatura ottimale nel orario

ONcaldaia(); //desideratoattesa;

}else{if(caldaia==ON)OFFcaldaia();

} }

controlloUmidità(){*per scopi futuri*

}return out_op; //out_op (how operate on out)}

out_plant(out_op){

… if true //if necessary out_pin(STR); …

else return;}

Comunicazione tra Raspberry e Nucleo

I dati acquisiti, via Web, da Raspberry vengono passati sulla porta seriale alla board ST tramite un file JSON che viene opportunamente strutturato su Raspberry in modo che ST lo possa interpretare.La comunicazione tra queste 2 schede avviene attraverso la porta seriale, la trasmessione dei dati avviene tramite UART (Converte flussi di bit di dati da un formato parallelo a un formato seriale asincrono o viceversa). Per collegare le 2 schede abbiamo utilizzato il pin 0 e 1 della nucleo e i GPIO 14 e GPIO 15 del raspberry.

richiesta del dato.Trsmettitore Trasmissione(){invio start byte; //sincronizzazione delle due schede if(leggiOK==TRUE){ incremento contatore; Leggodato(); calcochecksum(); //somma del valore del dato da passare e il contatore Inviocontatore; Inviolato; Inviochecksum; Do{ Aspettorisposta; If(risposta==ack) Break; Else If(risposta==nak) Trasmissione; Break;}while(1); }


106

}

Ricevitore:ricezione(){ If(start byte== e){ Leggi contatore; Leggi dato; Leggi checksum; Calcoloceksum2; If(checksum == checksum2) Invia ack; Else Invia nak; // se checksum != checksum2 reinvia il dato } }

Il sito Web e l’app

Il sito web (, figure sottostanti) illustra le caratteristiche del progetto e permette insieme all’app di monitorare da remoto i parametri dell’impianto. Il nostro sito Web è basato su tre punti principali l’esposizione del prodotto, i vari componenti usati (scheda st più componenti aggiuntivi e lego) e chi siamo

- la pagina dell’app : la foto mostra posizione (geolocalizzata) dell’impianto e la relativa temperatura e le condizioni metereologiche.

La conduzione del progetto

Il progetto è stato condotto cercando di seguire le procedure tipiche dettate dall’ingegneria del software (per quanto abbiamo appreso nella materia Tecnologia) seguendo un modello a spirale e una metodologia di sviluppo top-down funzionale, cioè basata su chiamata a funzioni. Questa tecnica ci è sembrata la più semplice e operativa, visto anche il tipo di linguaggio che abbiamo usato. D’altra parte abbiamo applicato il metodo bottom-up per quanto riguarda il riuso delle librerie messe a disposizione da ST e agli esempi trovati.

In particolare: ▪ Abbiamo identificato gli scenari e definito gli ambienti in cui si poneva il progetto (in particolare l’idea del

controllo, dei disturbi e di Ic)▪ Definito gli obiettivi finali ed intermedi (fig▪ individuato le procedure principali▪ determinato tempi, risorse e ruoli (primo/secondo quadrimestre, board e software, divisione in gruppi di

lavoro);▪ individuati strumenti idonei per il conseguimento degli obiettivi (ad es. la comunicazione di ST con Raspberry)


107

▪ procedure di test (non realizzate completamente)

Fig 5. La metodologia a spirale usata per la progettazione

La gestione del tempo

La gestione del tempo in relazione al progetto realizzato è stato uno degli elementi più critici dell’intero processo di sviluppo. Tenere i tempi previsti è stato molto difficile e ci siamo riusciti solo in parte (ad esempio la fase di test finale a campo è stata ridotta di molto!).Vediamone i motivi.

● Prima di tutto i requisiti non erano perfettamente chiari all’inizio (e un po’ anche alla fine!!) e sono andati maturando con il tempo (ma almeno in questo, la pianificazione fatta con il modello a spirale ci ha aiutati molto)

● In secondo luogo l’inesperienza che ci ha portato a sottovalutare i problemi che avremmo incontrato (comunicazione con altri sistemi, rapporto con lo staff di ST, ricerca della documentazione, ecc)

● In terzo luogo abbiamo deciso di sviluppare il progetto all’interno delle ore curriculari affinchè TUTTA la classe potesse partecipare e beneficiare degli stimoli offerti dal progetto. Ciò ha comportato una serie di interruzioni continue per lasciar spazio alle attività regolari, compreso l’uso dei laboratori per gli scopi didattici consueti

Tutto questo ha causato ritardi e incomprensioni ma, certamente, il risultato è stato decisamente positivo per una serie di ragioni:

● Prima di tutto la classe, forse per la prima volta, si è sentita investita di un compito e di responsabilità sia in termini tecnici che temporali

● La divisione dei compiti tra i gruppi ha permesso una collaborazioni intra e extra gruppo che ha richiamato le metodologie dell’ingegneria del software (indipendenza modulare, information hiding) applicate a un caso reale e concreto

● Le difficoltà di comunicazione e gli errori hanno fatto nascere la consapevolezza che la parte tecnica del lavoro è , sì, preponderante ma, assolutamente, non bastante in progetto. In particolare la gestione del tempo ha costituito un elemento forte di riflessione


108

Esercitazioni


109

Progettare con gli EAS

https://www.linkedin.com/learning/flipping-the-classroom/introduction


https://www.linkedin.com/learning/flipping-the-classroom/introduction

110

DUPLone AssemblerCostruire l’assemblatore di DUPLone

Esempi di progetti di ordine generale

Progettare una mensola porta-oggetti

Progettare la cuccia del vostro cane

(cfr. )

Alcune domande da porsi prima di iniziare Che taglia ha il cane? Dove deve trovarsi la cuccia : località geografica, enti atmosferici, esterna, protetta…? Materiale? Budget§? Attrezzi? Tempi di realizzazione? Controlli automatici? Sensori di temperatura, umidità, timer cibo/acqua? Giochi per cani? …


111

Progettare la potatura di una siepe

Progettare un giardino

Progettare un elicifero

(immagine a cura di Ferro)

Progettare una lampadina intelligenteFare un esempio di progettazione Top-Down per il seguente obiettivo:“Progettare una lampadina intelligente, a risparmio energetico, che si spegne quando si esce dalla stanza e si accende quando si torna “. (Si supponga di avere dei sensori e attuatori opportuni).

Per realizzare il progetto vi viene chiesto di fare una serie di passi progettuali.

Dare la definizione di requisito (dire sinteticamente cosa è, chi lo fa e a chi è diretto) e generare il documento deirequisiti del sistema di controllo della lampadina intelligente

Dare la definizione di specifica (dire sinteticamente cosa è, chi lo fa e a chi è diretto) e generare una specifica formale osemi-formale del sistema

Progettare il software separando il problema in sottoproblemi e operare secondo la modalità funzionale

Realizzare in (pseudo-codice) Javascript la struttura del programma che controlli il sistema e mostri su browser lo statodel sistema

Progettare un’applicazione Web per il lavaggio dei denti

Progetto n.Progettista

Scheda n. /ndata


112

BYT Brush Your Teeth

Obiettivi APP per imparare a lavarsi i denti rivolta sopratutto (ma non solo) a noin vedenti e bambini

DescrizioneSembra un gesto quasi banale, eppure lavarsi i denti è un rito assai più complesso di quanto si potrebbe pensare, perché bastano poche abitudini sbagliate per causare danni anche significativi. ….

Fasi del progetto e tempistica (allegare diagramma)

NOTA ricordarsi “intervista al cliente” che significa anche documentazione da ricercarsi in Internet nei siti specializzati di pediatria e altro genere

Risorse e strumenti

Risultati attesi in termini di prodotto/servizi e rapporto costo/benefici


113

Note aggiuntive

Sitogrfafia/Bibliografia

- http://www.corriere.it/salute/pediatria/cards/lavarsi-denti-8-errori-evitare/risciacquare-subito-denti_principale.shtml- http://www.dailymail.co.uk/health/article-4040028/Want-avoid-arthritis-brush-teeth-Experts-say-bugs-cause-gum-infections-trigger-crippling-joint-pain.html- http://www.orientamentomobilita.it/AP09-igiene_personale.html- http://www.studiomariolisa.it/IT/quante-volte-e-come-usare-lo-spazzolino-per-una-corretta-igiene-dentale/

app- https://itunes.apple.com/us/app/brush-teeth-toothbrush-timer/id1052694241?mt=8- https://itunes.apple.com/us/app/disney-magic-timer/id747541884?mt=8

Firma

Ideecontapedalate https://www.bdc-mag.com/forum/threads/uso-contapedalate-cardiofrequenzimetro.90726/


https://www.bdc-mag.com/forum/threads/uso-contapedalate-cardiofrequenzimetro.90726/

Business Plan “Il business plan è un documento che sintetizza i contenuti e le caratteristiche di un progetto imprenditoriale (business idea). Viene utilizzato sia per la pianificazione e gestione aziendale che per la comunicazione esterna, in particolare verso potenziali finanziatori o investitori.

La nascita di una nuova attività imprenditoriale (e di qualsiasi progetto aziendale) deve essere sostenuta da uno studio o un'analisi di fattibilità in grado di fornire una serie di dati di natura economico-aziendale, sui quali tracciare linee guida per la costituzione dell'attività. Per esempio, dato che l'impresa opera in un sistema di vincoli e opportunità, è indispensabile prima di avviarla conoscere i concorrenti e l'area strategica d'affari cui ci si intende rivolgere. Lo studio di fattibilità si concretizza nella redazione di un documento: il business plan.” (Wikipedia)

E’ alla base del progetto: gratificante, chiaro, pulito

A chi serve: A noi (Chiara Idea/ Obbiettivi /risorse/momenti e fasi/punto di riferimento /progressi /prezzi e costi) Aiuto nostri finanziatori (dimostra team vincente / competenze specifiche risorse esterne? Struttura

Compagnia /concorrenza /analisi mercato )

1. Sommario Esecutivo Idee importanti Dettaglio prodotto e vantaggi per chi investe Opportunità nel mercato Management Team Scansione dei tempi Proiezione finanziaria (realistica) Ricerca fondi e ritorni

2. Business Esperienze avute Struttura Manageriale Come posizionarsi sul mercato e vantaggi

3. vendite e marketing Che tipo di mercato Metodo di vendita/canali Prezzo è qualità in cosa differisce o somiglia Siete i primi?

4. management Competenze specifiche ruoli Siamo bravi Background team tutti/persone motivate da se è da noi stipendi e benefit Consulenti? chi? Se servon

5. operazioni Luogo sede strutture personale aggiuntivo

6. Financial forecast Convertire tutto in numeri Profitti e proiezione per un paio di anni Non essere troppo positivi Come entrano ed escono soldi quando? Realistici Come sopravvivere ai periodi bui?

7. Financial requirements

Tecno2 - L’ingegneria del software – paolo macchi - ISIS Facchinetti rel. 19.02.05 114

https://it.wikipedia.org/wiki/Comunicazione

https://it.wikipedia.org/wiki/Gestione_aziendale

Requisiti finanziari Dove quando ridare sicurezza rientro soldi Costruiamo la nostra credibilità finanziaria

8. assessing the riservati Consapevolezza criticità could be….ritardo meno vendite costi alti Come reagire Appendici Dettagli aggiuntivi Proiezioni finanziarie Analisi di mercato Clienti Altri dati

Scambiare idee Cercare più fondi di quello che serve Costi risparmiare Comunicare sempre con tutti i finanziatori Guida

Tecno2 - L’ingegneria del software – paolo macchi - ISIS Facchinetti rel. 19.02.05 115

Documents

Alcune immagini sono tratte da: ...moodle.isisfacchinetti.it/file.php/.../65/573/Tecno2_-_L_ingegneria... · ... il cuore della disciplina ... alla messa in opera e alla manutenzione