Home

Tecno2 - L`ingegneria del software - Paolo Macchi

1. 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 1 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 Scomponiamo il problema man mano che lo affrontiamo Al primo livello di scomposizione abbiamo la coincidenza cc 3 sl Li VERO e FALSO alii n a l problema stesso Al secondo abbiamo due sotto problemi distinti 2 d VERO p A RS z FALSO dl CAI DO CALCOLA IL i Asg gt 8 RICMICE IL VALORE DIX E Ss T KM MUC D A B VALORE ASSOLUTO er YIN MODA TALE CHE i WAE _ e _ M C0 A BM C0 xY CEIA Ye IB KEA KE A 3 CALCOLA SR PA
2. ecnoZ L ingegneria del soitware paolo macchi acchinetti 48 Diagrammi relativi agli aspetti statici di un sistema Diagrammi dei Casi d uso e 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 Ad esempio Esempio Acquisto di un prodotto Sistema di gestione ordini Moreno Mirzolla ingegneria del Soltamre e Descrive le modalit di utilizzo del sistema come visto dall utente attore Si rapopresenta 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 prelievo bancomat s lt include C Dee extends ini a D controllo retina stampa ricevuta controllo password s qeneralizza verifica identit http www ba infn it regano tesi tracker model file UML html Diagrammi di Classe degli Oggetti Descrive la scomposizione in classi e le relazioni tra esse Inoltre mostra una rappresentazione delle istanze delle classi cio gli oggetti residenti RigaOrdine residenza strada string cap int citta string provincia string eCenoz L 1 ngegneria del software paolo macch acchinetti 49 Partendo dalle specifiche del sistema si ricavano le c
3. Descrive l organizzazione gerarchica dei moduli di un programma Un esempio classico la struttura ad albero con Call e Return A Un esempio di programmazione Top Down funzionale Come esempio si applicher il procedimento descritto alla risoluzione del seguente problema http ennebi solira org c lang pag29 htm 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 risultati Fine In questa prima approssimazione si sono evidenziati 1 risultati intermedi da conseguire affinch il problema possa essere risolto
4. interazione flessibile o input deve essere possibile attraverso pi canali tastiera men Ogni azione deve poter essere interrotta o annullata Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 43 o Nascondere all utente 1 dettagli tecnici e Prevedere modalit d uso abbreviate macro o short cut per utenti esperti e 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 Analisi e modellazione degli utenti dell ambiente e delle operazioni Progetto dell interfaccia Implementazione dell interfaccia Validazione dell interfaccia Analisi dell utente dell ambiente delle operazioni Convalida dell interfaccia Progettazione Implementazione dell interfaccia NOTA Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 44 L interazione uomo macchina linee guida e standard L interfaccia uomo macchina uno degli elementi caratterizzanti un sistema informatico Infatti ogni applicazione pu essere classificata anche sulla base della modalit con cui si presenta all utente e viceversa grazie alla quale l utente pu interagire con l applicazione Questo elemento solitamente indicato con il nome interfaccia utente racchiude
5. paolo macchi Tecno l ingegneria del software Come do ha speegafo Come io da descritta il ekirinte ppt Laree H Bunnes Contenitori Come stato dommentato Qual operazioni sono Cuanto stato fatturato P AE E VIS RA Quella di cui H ekentt il progetto State svolte alchemie i i areva realmente birermo ISIS Facchinetti 2015 Tecno 2 l ingegneria del software ISIS Facchinetti 2014 15 Gli appunti contenuti in questa dispensa si basano essenzialmente sugli appunti del prof Moreno Marzolla a cui sono totalmente debitore http www moreno marzolla name teaching IngSoftware2005 index unife ph Alcune immagini sono tratte da http www youtube com playlist list PLggAc4E1vc2vxNkgLK6EZXCkBbsaAvwvC Approfondimenti si possono trovare anche in http studenti di3 units it Sistemi 20Informativi 201 Slide 20Progettazione 20 28e 29 pdaf http www federica unina it ingegneria ingegneria del software ingegneria introduzione ingegneria software 2 http home deib polimi it morzenti IngSw cicliDiVita pdf 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 www isisfacchinetti it
6. 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 Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 39 Inizio Per indice da 0 a 11 Ricevi temperatura rilevata Fine per Fine 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
7. 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 utente 2 Limitare la necessit per l utente di fare ricorso alla propria memoria 3 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 nterfaccia 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 Controllo nelle mani dell utente Definire la modalit di interazione in modo da non costringere o utente ad azioni inutili o indesiderate es prevedere la possibilit di modifica del testo anche in fase di correzione ortografica Offrire sempre un
8. dopo la quale la Macedonia fu divisa in quattro repubblichedipendenti da Roma cui furono pesantemente limitati i rapporti reciproci nonch quelli con gli altri stati ellenici Wikipedia i eenn dell impero comano tar de A egare La nl maggior peris delle le gmoni CO cani dei impe E E vaali mo tare ta se confini dei Meno e del Mosubio tfesr fareste sanarinna LI cs homi ia Bit creta fare fer n e ia haon dini ae ni fa iper argine n P i 7 L_ Droe ipah E Hannan te la G regna dri Panta deke e Ad Ad http www romanoimpero com 200 is Dige d A E pMa mi pRa 9 1 ai na 9 06 a ugusto 27 ac 14 html es Chi conosce tutti i dettagli di un automobile NESSUNO Motoristi meccanici divido la macchina in es il software lo divido in basi dati funzioni presentazione Modularit Identificare moduli che possono essere riusati Modularit Dividere il sistema in moduli che hanno alta coesione e basso accoppiamento pochi link ricorda legami forti e debol1 Riusati e integrati Divisione Processo in fasi fasi in attivit attivit in sottoattivit Es il test in varie fasi per collaudare 1l sistema per gestire la complessit Attenzione per i link DEVONO ESSERCI se no si torna a due diversi sistemi indipendenti Moduli diversi disaccoppiati sono due sistemi completamente diversi e Astrazione Ignorare i dettagli Ragionare sui MODELLI ex circuit
9. il segnale di riconoscimento che ci indicher se quello che abbiamo in ingresso qualcosa che viene riconosciuto oppure non viene riconosciuto 0 non riconosciuto 1 riconosciuto Gli automi riconoscitori vengono utilizzati ad esempio dai software traduttori I software traduttori sono molto importanti infatti ci permettono di tradurre un programma scritto in un linguaggio di programmazione vicino all uomo in un linguaggio binario vicino alla macchina In ambito informatico per esistono altri ambiti in cui vengono utilizzati gli automi riconoscitori pensiamo ad esempio a quando accediamo all elaboratore con l inserimento di una password Pensiamo ai robot in grado di riconoscere comandi forniti dall ambiente esterno 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 Esrcizi http magistri altervista ore SISTEMI quarta Esercizi sugli Automi pdf Esempio 2 1
10. sezione download per fini esclusivamente didattici e non commerciali Segnalazioni di errori critiche e consigli sono molto graditi e possono essere inoltrati a paolo macchi libero it oppure lasciando un commento al momento del download per gli studenti registrati Tecno2 L ingegneria del software paolo macchi ISIS Facchinetti 151005 ISIS Cipriano Facchinetti via Azimonti 5 21053 Castellanza VA http www isisfacchinetti it Tel 0331635718 fax 0331679586 info isisfacchinetti it Convenzioni usate nel testo rappresenta una curiosit un approfondimento NOTA rappresenta una nota A rappresenta una esercitazione o esempio http greode kaywa com link di riferimento Rappresenta un codice o dei risultati o una segnalazione storica Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 1 Sommario Peres ia all 4 QAS ACER IE AA i COM 6 COLUI nni 6 Leda Ae dEi 7 Caratteristiche diun Prodotto SOTWAleso dai J Ee e EE E I e e E A A AAE A E EE A E A E T E 7 CIONI EEE E ZA 6 Perce I MECE a Ae SO WICC MPA iaia 6 Cost nel processo di produzione del Soltwaferrrari tata 9 Il processo di produzione del Sollware ilaria 10 ROERO OTT 10 Modello dei principi dell ingegneria del Software iiii 11 Principi fondamentali il cuore della disciplina 11 Il processo di produzione sviluppo del software iii 14 Problemi nel proces
11. FALSO x M C D X Y VERO e ari lt B gt 0 gt e gt x http homes di unimi it anisetti Teachinge lezione 205 pdf ecno2 L ingegneria del software paolo macchi acchinetti 36 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 e Scomponibilit o Un metodo che permette la scomposizione del problema in sottoproblemi riduce la complessit e Componibilit o Un metodo che permette l assemblamento di componenti preesistenti migliora la produttivit e Comprensibilit o Un modulo le cui interfacce con altri moduli siano minime di pi facile costruzione e modificabilit e Continuit o Modifiche al requisiti del sistema che comportano solo modifiche a singoli moduli e non all architettura generale sono di facile controllo e Protezione o Seeffetti anomali in un modulo non si propagano si ha un miglioramento della mantenibilit Indipendenza Modulare Per ottenere una modularit effettiva 1 moduli devono essere indipendenti ossia devono occuparsi di una funzione ben determinata nelle specifiche dei requisiti ed interagire con g
12. ci si deve aspettare Quando la distanza tra 1 due modelli mentali ampia il livello complessivo di usabilit dell applicazione informatica pu essere molto basso e l utente pu andare incontro a problemi di comprensione nell utilizzo dell applicazione stessa Cos come i moduli software anche le interfacce grafiche devono essere sottoposte a opportune fasi di test in grado di verificare non solo il loro funzionamento ma anche l effettiva aderenza tra 1 requisiti utente e l interfaccia creata In questo ambito sono spesso utilizzati 1 test case quali ipotetici scenari di riferimento che simulano il comportamento dell utente finale Rispetto al test di un interfaccia programmatica il test di un interfaccia utente risulta molto oneroso in termini di definizione dei test case visto il numero delle possibili funzionalit solitamente offerte da un applicativo Inoltre il grado di libert dell utente molto elevato ed difficile riuscire a coprire il grande numero di azioni che possono essere compiute sui controlli che compongono l interfaccia Modelli basati su macchine a stati possono divenire intrattabili visto il numero di stati nei quali un utente si pu trovare Sono pertanto stati proposti alcuni modelli che cercano di ridurre questa complessit lasciando comunque una buona copertura delle possibili situazioni Nella fase di valutazione della bont di un interfaccia di particolare importanza la valutazione dell
13. 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 cambiamenti I 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 e Cambiamenti nel corso dello sviluppo e Cambiamenti in essere una volta sviluppato il prodotto Il modello legato a uno Sviluppo Evolutivo primo tipo producono feedback e concetti nuovi secondo tipo costruzione incrementale del sistema sviluppiamo vari livelli Sviluppo incrementale iterativo Un idea fondamentale dello sviluppo incrementale o iterativo quella che alcune parti di alcune attivit vengono rimandate 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 1 risultati sono codificat
14. 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 punti la cui somma delle distanze dai due pioli costante e coincide con la parte libera della funicella wikipedia oppure con una propriet geometrica descrittiva Per definizione l ellisse il luogo dei punti la cui somma delle distanze da due punti fissi detti fuochi costante cio F1 X1 F2 X1 F1 X2 F2 X2 K costante ax 2 by 2 c 0 Linguaggi di specifica Molti sono 1 linguaggi di specifica usate Qui ne mostriamo come esempio alcune Diagrammi di flusso dei dati operazinale e semiformale Notazione grafica Hanno avuto enorme successo in passato o Processi unit di memoria flussi entit esterne connesse inizio leggi il primo numero A primo numero leggi il secondo numero B secondo numero ecnoZ L ingegneria del soitware paolo maccnhi acchinetti 28 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 Specif
15. efficiente il meno costoso 1l pi mantenibile 11 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 progetto dovrebbe rimanere comprensibile e i cambiamenti dovrebbero avere effetto locale La Specifica del Progetto La specifica del Progetto 11 documento che descrive il progetto finale con questo formato Descrizione della portata globale del progetto ricavata dalla specifica dei requisiti e Descrizione del progetto dei dati struttura del DB file esterni dati interni riferimenti fra dati e Descrizione dell architettura con riferimento ai metodi utilizzati per ricavarla rappresentazione gerarchica dei moduli e Progetto delle interfacce interne ed esterne descrizione dettagliata dell interazione utente sistema con eventuale prototipo e Descrizione procedurale dei singoli componenti in linguaggio naturale Le fasi di progettazione Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 31 SS Asrchitottura tal sistima 1 Disegno Architetturale a Identificare e documentare 1 sottosistemi e le loro relazioni 2 Specifica astratta a Specifica 1 servizi forniti da ciascun sottosistema e 1 vincoli sotto cui il sottosistema deve operare La specifica delle interfacce deve essere non ambigua dato che deve consentire di definire 1 sottosi
16. il sistema va rifatto Tecno L ingegnerla del software paolo macchi ISIS Facchinetti 5 1005 19 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 Schema del modello a Spirale A rig E gimi rpari Pianiflcacr cane N nai j R a Pi ma a Cei San A dllanta fa oi parti d oniri Chirevftturassoana abua Fiona da parte ei clienti Dogna riorhia a rile 00 Fropiatii di manifenzione ci ua parioado rio Progetti di migf oramsernto di un prodotta essa Progetti di milope di un nudi presso E rogito di nuove kisia Breno Marzo la irgegnerta del Softaare dI La spirale divisa a spicchi e Comunicazione con il Cliente Specificare gli obiettivi e i vincoli di quella fase identificare i rischi ed eventualmente proporre delle strategie alternative e 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
17. 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 L ingegneria del software e punta a produrre software affidabile sicuro usabile e manutenibile e diversamente dalla programmazione non si preoccupa solo della funzionalit o di particolari caratteristiche del sistema e 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 alla l ingegneria del software si occupa degli aspetti pratici base dei sistemi software ed informatici relativi alla produzione del software Anche se le teorie ed 1 principi informatici sono fondamentali spesso vengono trascurati dagli ingegneri del software per questioni di praticit diversamente da quanto accade in altre branche ingegneristiche L effetto delle modifiche Costo di una modifica Definizione Sviluppo Dopo la consegna ecno2 L ingegneria del software paolo macchi acchinetti g I miti del management cliente programmatore Abbiamo standard e procedure da seguire nello sviluppo Non ci serve altro Abbiamo i pi moderni sistemi di sviluppo Acquistiamo i computer sempre pi recenti Sviluppare no
18. 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 il tasto 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 1l grafo P3 Pronto a 2 ore minuti m Pronto ese giorno ecnoZ L ingegneria del software paolo maccnhi acchinetti 69 Esercizi Esercizio n 0 parzialmente risolto La macchina accetta monete da 1 e 2 euro I nessuna moneta le 2e e Fornisce il prodotto quando viene raggiunto l importo di 5 euro uscita a 1 Convenzione chiamiamo ogni stato della macchina con l importo raggiunto 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 I 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 dat
19. nstallazione in fmzione Manutenzione 1 Studio di fattibilit cosa Definizione di che COSA deve essere fatto e non come deve essere fatto ecnoZ L ingegneria del software paolo maccnhi acchinetti 15 stabilire se lo sviluppo debba essere avviato COSTIBENEFICI quali le alternative possibili e le scelte pi ragionevoli stima delle risorse finanziarie e umane necessarie per ciascuna possibile 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 il problema e formularlo correttamente per chi deve risolverlo Si va dal cliente e si cerca di capire il problema NB 1l cliente pu essere il mercato e non necessariamente in carne e ossa e Definizione del problema tramite interviste con il commitente di funzioni vincoli prestazioni interfacce e di qualsiasi altra caratteristica che il sistema dovr soddisfare e 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 predisposizione di un piano di test e della versione o del manuale utente e Si produce un documento una specifica dei requisiti da passare alla fase di progettazione 3 Progettazione come Capito il problema nelle fasi precedenti si cerca di trovare una SOLUZIONE al p
20. 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 release in modo da avere un riscontro dagli utenti 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 Phases Disciplines inception Elaborationi Construction Trarafion E Business Modeling S Requirements Analysis amp Design D Implententation m Tesi m Deployment a Configuration amp Change Mami E Project Managermeni E Environment iterations Un esempio di sviluppo incrementale 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 AI cliente il prototipo potrebbe apparire funzionante ma in realt potrebbe avere tali e tanti problemi da renderlo di fatto inutilizzabile in condizioni reali Quindi
21. precoce che pu iniziare appena il primo modulo stato specificato Questo approccio comunque induce il rischio che 1 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 1l resto dell industria informatica I metodi top down erano 1 preferiti nell ingegneria del software negli anni ottanta Il Divide et Impera e il top down Il Divide et Impera la speranza di risolvere un problema irrisolvibile ssomponendolo 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 contrario quello dell Orda Mongola Tecno L ingegnerla del software paolo macchi ISIS Facchinetti 5 1005 35 Il Divid
22. quell insieme di funzionalit di comunicazione in cui l utente dell applicazione pu essere fonte o destinatario del messaggio Queste funzionalit rappresentano la parte visibile di un applicativo e permettono l inserimento dei dati di input e la visualizzazione dei dati di output Sebbene storicamente le prime applicazioni per elaboratori fossero di tipo batch quindi pi legate all analisi dei dati attualmente le applicazioni interattive in cui l utente e l applicazione dialogano costantemente a costituire gran parte delle soluzioni Indipendentemente dalla tecnologia e dalle modalit di interazione spesso accade che il progettista di un applicazione informatica sviluppi una propria idea del profilo utente e dei requisiti dell applicazione in sviluppo senza mai avere incontrato gli utilizzatori finali In questi casi 11 modello concettuale dell applicazione sviluppato dal progettista che corrisponde a ci che egli immagina dei bisogni dell utente e alle soluzioni che implementa per permettere all utilizzatore finale di raggiungere nel modo pi efficace 1 propri obiettivi pu non coincidere con il modello che si creato l utente il modello mentale dell utente corrisponde all idea che egli sviluppa del funzionamento dell applicazione delle operazioni eseguibili su di essa dei comandi che vengono resi disponibili dall interfaccia delle azioni necessarie per fornire il proprio input e dei tipi di output che
23. riconosce la sequenza e solo in questo caso emette 1 in uscita ecno2 L ingegneria del software paolo macchi acchinetti 65 0 1 0 100 Esempio 2 2 Generatore di parit 0 0 0 1 OUT 1 se il numero di 1 dispari 0 se pari ESEMPIO 2 3 http terzablst altervista org automiriconoscitori html Dato l alfabeto costituito solo dalle lettere M 0 V A riconoscere la parola MOV Alfabeto M O V A OUT 0 non riconosciuto 1 riconosciuto ecnoZ L ingegneria del soitware paolo maccni acchinetti 6 6 A we err so semo semo Es 2 4 Sequenze sovrapposte 101 e 110 Pattern 1 Pattern 10 e es 1 00111101100101 sovrapposizione http www dsl unive it arcb AA01 02 SLIDES 12 ese circ_seg2 pdf Esempio Reralizzazione di una macchina a stati applicata mediante Assembly 8086 ecno2 L ingegneria del software paolo macchi acchinetti c Mon IN C F OUT Mon m OFF CiMon Moff Il 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 3 IN0XXXXXXXX a chiave 1 on 0 off fine corsa 1 on 0 off Porta o varout0 OUTOXxxXxxxxXxx Imotore 1 on 0 off VINCOLI OGGETTIVI l1 una chiave mett
24. usabilit definita come la misura in cui una tecnologia pu essere usata da particolari utenti per raggiungere certi obiettivi con efficacia efficienza e soddisfazione in uno specifico contesto d uso Da questa definizione risulta evidente che ogni volta che si parla di usabilit ci si riferisce sempre al contesto di utilizzo del prodotto evidenziato sia dalla particolare classe di utenti sia dal tipo di attivit svolta con l ausilio del prodotto stesso Il concetto di usabilit si sviluppato all interno dell ergonomia tradizionale ma fin dal suo sorgere ha avuto forti rapporti con l ergonomia cognitiva e pi in particolare con gli studi volti a migliorare l utilizzo dei prodotti a base informatica soprattutto il software Concettualmente l usabilit di un prodotto in particolare software misura la distanza cognitiva tra il design model il modello di funzionamento del prodotto che l utente si costruisce e che regola la sua interazione con il prodotto quanto pi 1 due modelli sono vicini tanto meno l usabilit un problema In questa prospettiva assume rilevanza cruciale l interfaccia del prodotto a base informatica essa deve rendere immediatamente conto delle possibilit dei limiti e delle modalit di funzionamento del sistema evidenziando la relazione tra le azioni che l utente pu compiere manipolare oggetti spostarli ecc e 1 risultati che pu ottenere tralasciando le operazioni e le computaz
25. 3 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 11 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 afferma la legge di Mayers E bene trascurare la fase di analisi e progetto e passare immediatamente all implementazione cos da gudaganre 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 clinte cio di colui al quale deve essere fornito il prodotto Ma come avere conoscenza del problema Prima di tutto Cosa si deve fare Analizzare la situazione reale in tutte le sue sfaccettature ascoltare il cliente studiare le problematiche aperte acquisire comptenza sulle tematiche in gioco Infine crear
26. EAS concettuale Forisce uno stimolo Da ma consera mm Lemme bvdare Organizza il lavoro individuale codi artefatto iope Valuta gli artefatti Aralizza criticamente eli Refective Leamine Comegge l misconceptions artefatti Fissa iconcetti Sviluppa riflessione processi attivati htt linanimatealice edu au A DUPLone Assembler Costruire l assemblatore di DUPLone Tecno L ingegnerla del software paolo macchi ISIS Facchinetti 5 1005 60 Esempi di progetti di ordine generale A Progettare una mensola porta oggetti https it formabilto com pro getto concorso nuvola 4414 A Progettare la cuccia del vostro cane cfr http www insidehomeart it tutorial falegnameria 380 come realizzare una cuccia in legno showall 1 amp lImitstart 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 o Sensori di temperatura umidit timer cibo acqua Giochi per cani A Progettare la potatura di una siepe A Progettare un giardino Tecno L ingegnerla del software paolo macchi ISIS Facchinetti 5 1005 61 Appendice 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 sem
27. FP Frofessional 5HomeEdition i suddetti sistemi operativi devono essere pre installati 1 Giapponese inglese tedesco cinese semplificato cinese tradizionale Lingue iu italiano francese spagnolo portoghese coreano p Windows 7 dewe rispettare i requisiti di sistema per il sistema operativo Requisiti di sistema croata Windonws XP Pentium Ill o superiore velocit di clock 1 GHz o superiore Windows 7 deve rispettare i requisiti di sistema per il sistema operativo Windows XP 512 MB o pi consigliato 1 GB o pi Snazio di T Ballo isco La iesto 1 GB o pi per l installazione i Risoluzione 1024 x 769 pixel o superiore colore di visualizzazione High Monitor 1 i Color 16 biti o superiore Condizioni operative Dewe essere installato NET Framework 2 0 SFZ 2 Me moria RAM Cosa sono le specifiche Le specifiche 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 specifiche Il risultato del processo di sviluppo verr valutato sulla base del fatto che soddisfi o meno le specifiche Specifiche formali e informali Il documento delle specifiche descrive in modo formale ci che far 11 software e le sue parti moduli e Le specifiche informali che sono le pi diffuse sono formulate in linguaggio na
28. GHETO TOCA http eliasmengwee wordpress com category linee sottili page 2 Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 47 Soluzioni per la progettazione UML UML un linguaggio di modellazione cio una notazione anche grafica usata per esprimere le caratteristiche di un progetto nell ambito della programmazione ad oggetti Esso cerca di fornire una soluzione completa alla progettazione di un sistema sia da un punto di vista statico che dinamico e UML il successore di una serie di metodologie di analisi e progettazione orientate agli oggetti Il processo proposto da UML consiste in una serie di consigli riguardanti 1 passi da intraprendere per produrre il progetto stesso e 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 insieme Per un approfondimento http www analisi disegno com uml introuml pdf Tipi di diagrammi UML Esistono due grandi famiglie di diagrammi che descrivono aspetti diversi del sistena e aspetti statici o casi d uso o diagramma di classi e aspetti dinamici o diagrammi di sequenza o diagrammi di stato o diagrammi di attivit o Diagrammi dei Componenti e di Deployment un esempio Viste diverse del Duomo di Milano Il nostro percorso in Duomo
29. Traduciamo i componenti individuati nel progetto in codice in realt non si tratta solo di tradurre ma occore una buone dose di intuizione 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 Testing Definizione 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 1 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 il committente Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 16 e Test di sistema 7 Manutenzione Processo 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
30. Z L ingegneria del soitware paolo maccnhi acchinetti 53 Decisioni CJ IOo Rical Bisoi bRioren Harpon ruga grana GH Sani http www simple groupware de cms ext files WebDisk uml deployment eif Diagrammi dei Componenti e di Deployment e Mostra come sono organizzate le componenti fisiche del sistema file librerie eseguibili moduli PO PO bl CI Windows Explorer C bd wWebzerver CJ Apache Tomcat CO Java Servlet E jcIFS C C Dateizerver CO Dateisystem L_r Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 54 Collaudo del software Collaudo del software test Garantire che il sistema software sia privo di errori e difetti Principi fondamentali e 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 e Scoprire i difetti presenti nel sistema verifica o Stiamo costruendo il software in modo corretto o Il software deve essere conforme alle specifiche cio deve comportarsi esattamente c
31. a associazione possono essere etichettati con il nome del ruolo Se non indicato il ruolo 11 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 I rdine data Cliente Molteplicit obbligatoria i prepinat E a piecze Dena f spedisci chiii E di ecno2 L ingegneria del software paolo macchi acchinetti 50 grar Department 1 1 l it addInstrucetori removelnstructori petinstructon pa Allnztructorz pho addstuderti removeStudenti petStudent petAllSudentsi addDeparnmenti remove Departmenti ctD bi EctALDepartmente 7 s di r A Member L 0 1 name Name mime Nome name Same student Di Number courselD Number i af Moreno Marzolla Ingegneria del Software 2 CodiceCliente charf3 o rdine Usemam e String codicsordine sint E e Effettua role CodiceCliente charf3 Nome string CodiceP rodotto String Citta String e O FrezzoGiuantita double n arola CodicetCliente char descrizioneProdolto S descrizioneProdotto String comprende unitamizura char2 Quisntit Ordine double FrezzoF rodot
32. a una sequenza di 0 e 1 in ingresso e dal simbolo terminale T fare in modo che l uscita finale sial o 0 rispettivamente se il numero di 1 rilevati sia dispari o pari Esercizio n 5 Costruire la macchina a stati sia in forma di grafo che di tabella di un distributore di bevanda 1 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 1 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 1 ascensore ha i pulsanti Piano Terra PT e Piano 1 P1 Le azioni sono Sali e Scendi Esercizio n 7 Supponiamo di avere un sistema che si pu trovare in uno stato appartenente ad un insieme finito di stati possibili Fx Immaginiamo un incrocio tra due strade regolate tramite semafori Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 70 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 in funzione degli ingressi e dello stato corrent
33. abile 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 1 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 macchina evitando la somministrazione di dosi eccessive I controlli hardware erano stati eliminati e sostituiti da controlli software probabilmente per contenere 1 costi http courses cs vt edu cs3604 lib Therac 25 Therac 1 html http it wikipedia org wiki Therac 25 Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 5 A Esercizio Trovare 3 esempi di errori software che hanno causato incidenti o problemi Costi del Software Le economie di tutti i paesi sviluppati dipendono dal software e la maggior parte dei sistemi sono controllati da software Sempre pi sistemi sono controllati dal 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 so
34. aforo 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 esattamente come 1 biologi classificano insetti o piante Ad esempio distinguiamo i mammiferi dagli ovipari 1 vertebrati dagli invertebrati Anche per 1 sistemi possiamo cercare di classificarli in funzione di alcune loro caratteristiche salienti I sistemi possono essere classificati in base a La Natura 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 e Naturali gt esistenti in natura e Artificiali gt realizzati dall uomo e Misti gt naturali ma modificati dall uomo es dighe Se il criterio di classificazione il tempo dobbiamo distinguerlo in e Discreto gt 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 e Continuo gt 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 1 numeri reali etc Se il criterio di classificazione si basa sulle propriet delle var
35. arie 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 Tecno L ingegnerla del software paolo macchi ISIS Facchinetti 5 1005 10 http www dia uniroma3 1it cabibbo asw pdf asw210 processi software pdf Modello dei principi dell ingegneria del Software http www youtube com playlist 1ist PLggAc4E1ve2vxNkgLK6EZXCkBbsaAvwvC I campi dell ingegneria del software e 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 e 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 e 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 e Strumenti sono 1 tools che applichiamo alle metodologie Principi fondamentali 1l cuore della disciplina e Rigorosit e formalit o L uomo sempre l elemento essenziale ma si migliora si amplifica con dei c
36. ate Progetti software Il lavoro di ingegnerizzazione del software viene normalmente organizzato in progetti 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 Tipi principali di progetto e Modifica di software esistente e Sviluppo di un sistema da zero e Sistema nuovo costruito con componenti gi esistenti Progetti software In generale non possiamo produrre software nella manierapi immediata 1 I progetti sono in genere di dimensioni consistenti 2 Possono richiedere l applicazione di pi strumenti linguaggi di programmazione algoritmi 3 Possono coinvolgere pi persone sviluppatori committenti e utenti A Esempi Sviluppo di e Un compilatore un editor un sistema operativo e Un applicativo web e L implementazione di un algoritmo di ordinamento e Un dimostratore automatico e Progetti software ingegneria software ecno2 L ingegneria del software paolo macchi acchinetti 59 A Esempio programma di elaborazione testi e Stadio 1 funzioni base relative alla gestione dei file al trattamento del testo e alla produzione di documenti e Stadio 2 funzioni pi raffinate di trattamento del testo e di produzione dei documenti e Stadio 3 controlli ortografici e grammaticali e Stadio 4 funzioni avanzate di impaginazioneIl modello incrementale 3 Progettare con gli
37. attivit distinte e Testing confermare la presenza di errori e Debugging localizzare e correggere tali errori Strategie Problemi e Limitazioni Strategie 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 Tecno2 L ingegneria del software paolo macchi ISIS Facchinetti 151005 56 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 Impossibilit di produrre tutte le possibili configurazioni di valori di input test case in corrispondenza di tutti 1 possibili stati interni di un sistema software Ulteriori Problemi In 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
38. campo del software si ha a che fare con sistemi discreti per 1 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 repent BO if R1 then uf R2 then if R3 then Bi else B2 ndif if R4 then A3 else B4 emi else B3 edit endif until R6 Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 57 Esercitazioni La brevit consiste nel dire molte cose in poche parole e se fosse possibile a far pensare pi di quanto si dica Roukhomovsky 2001 Fare progetto http www dmi unict it nicolosi LezioniPS200809 Lezione1 pdf http www giullodestri it ingsw shtml Obiettivi Coinvolgervi nello sviluppo di un progetto software in cui 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 e un leader e uno o pi analisti e due o pi programmatori Sarete voi a scegliere il ruolo pi adatto alle vost
39. citure Con questo metodo si pu provare il capo in lavorazione man mano che si produce e 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 http it answers yahoo com question index qid 20121106003108AAkFkD9 Top down Il problema viene partizionato ricorsivamente in sottoproblemi fino a che si identificano dei sottoproblemi trattabili La programmazione top down uno stile di programmazione fondamento dei tradizionali linguaggi procedurali nel quale la progettazione inizia specificando parti comp
40. 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 e Il sottoprogramma facilmente esportabile e 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 e Qualora si avesse necessit di modificare una parte del programma ci pu avvenire facilmente basta sostituire solamente 1l sottoprogramma che esegue l elaborazione da modificare Il resto del programma non viene interessato dalla modifica effettuata e 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 ATTENZIONE Non 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 cau
41. di intergrazione pi a rischio e Strutturazione Attivit rivolte a costruire una o pi rappresentazioni strutture alternative del sistema e 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 11 compilatore sia bacato I rischi sono conseguenza di informazioni insufficienti Si risolvono acquisendo maggiori informazioni per ridurre l incertezza Vantaggi del Modello a Spirale e Valutazione esplicita dei rischi e Adatto allo sviluppo di sistemi complessi di grandi dimensioni e Interazione con il cliente ad ogni giro della spirale Svantaggi e La stima dei rischi richiede competenze specifiche e Seirischi non vengono valutati correttamente potranno sorgereproblemi nelle fasi successive e Il modello relativamente n
42. e AUTOMI DETERMINISTICI SULL ALFABETO E f a b Costruire gli automi finiti deterministici sull alfabeto E a b che accettano 1 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 UOMO CAPRA LUPO CAVOLO Costruire un automa finito deterministico che rappresenta il seguente problema Un uomo deve traghettare dalla sponda sinistra alla sponda destra di un fiume tre passeggeri una capra un lupo e un cavolo L uomo ha a disposizione una barca che gli consente di portare dall altra parte un solo passeggero alla volta Inoltre egli non deve lasciare incustoditi sulla stessa sponda del fiume a la capra con il cavolo b il lupo con la capra Per la costruzione dell automa etichettare 1 vari stati con la seguente notazione e C L V U Capra Lupo caVolo Uomo sulla sponda sinistra C L V U Capra Lupo caVolo sulla sponda sinistra Uomo sulla sponda destra ecc Gli eventi saranno u l uomo compie la traversata da solo uc l uomo compie la traversata con la capra ul l uomo compie la traversata con 1l lupo uv l uomo compie la traversata con il cavolo Una volta costruito
43. e 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 allora anche 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
44. e in moto 11 motore del cancello 2 11 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 0 ends DEFINE INO EQU 00h OUTO EQU 01h stack segment dw 128 dup 0 ends code segment start set segment registers mov ax data mov ds ax mov es ax MOFF mov dx INO Ingressi e uscite non usate in questo esempio sin al dx mov al varin0 Controllo sulla porta per la chiave and al 00000001B jz MOFF Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 68 MON or al 00000001B Accensione motore mov varout0 al mov dx OUT0 out dx al NonFine mov dx IN0 sin al dx mov al varin0 and al 00000010B Aspetta lo switch del finecorsa cmp al 00000010B jnz NonFine and al 11111110OB 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 ends end start Esempio 4 Regolazione di un orologio digitale http www dettori info dettori_old automi htm L orologio munito di tre pulsanti la cui pressione chiameremo PI P2 P3 che servono per la regolazione delle ore minuti mese giorno e per il passaggio dalla modalit del display in cui vengono
45. e un modello che rappresenti questa realt In secondo luogo ma solo dopo Come si deve fare Progettare una soluzione usando tecniche metodologie e strumenti adeguati Un aiuto ci viene dall Ingegneria del Software che cerca di mettere ordine in una materia che ancora giovane si pensi che gi 1 Romani pi di 2000 anni fa erano esperti nella costruzione di Ponti mentre 1l software una materia relativamente giovane che risale a50 60 anni fa Il termine fu coniato durante la seconda guerra mondiale si veda http it wikipedia org wiki Software Storia_del_software Mita n https www flickr com photos 22996675 N07 19631190694 in dateposted public pont du Gard ponte romano nel sud della Francia 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 Ecco perch non basta la buona volont come spesso si dimostra osservando 1 risultati di progetti di laboratorio ma Tecno L ingegnerla del software paolo macchi ISIS Facchinetti 5 005 4 occorre una disciplina che sia in grado di fa
46. elli progettando in dettaglio le componenti e le loro sotto componenti fino a Tecno L ingegneria del soltware paolo macchi ISIS Facchinetti 151005 30 quando si raggiunge un livello in cui le componenti non possono pi essere ulteriormente suddivise Astrazione E 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 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 1 dettagli emergono Via Via Metodologie per la progettazione di sistemi cfr http studenti di3 units it Sistemi 20Informativi 201 Slide 20Progettazione 20 28e 29 pdf Qualit di un progetto La qualit dipende da specifiche priorit di tipo organizzativo Un buon progetto potrebbe essere 1l pi
47. ema per aprire la sbarra leggere un sensore azionare un attuatore e garantire 1 requisiti e cosa l utente chiede al sistema e ci che deve garantire il sistema requisito del Dominio Applicativo e cosa deve fare il sistema per soddisfare 11 dominio applicativo Specifiche garantire 1 requisiti D A gt parcheggio esterno al sistema Sistema gt controllo del parcheggio Cosa comprende 1 D A e cosa 1l Sistema di controllo Ad esempio Sensore in ingresso attivo comprende entrambe i domini legge l automobile ma anche del sw che lavorer sul segnale di ingresso Tessera valida entrambi Veicolo autorizzato gt D A Varco aperto gt D A il sistema NON vede il varco aperto Apri varco inviato alla sbarra da parte del sistema I valori interni al sistema qui non mi ineterssano mi interessano le realzioni interasezioni tra 1 due L intersezione necessaria tra 1 due domini Li i fo DI LI re E jS P ii ia i k Li N eicolo rizzato Fenomeni condivisi valida Sistema Dominio applicativo I Nege Ti egnale esaurito Apri Wal Tecno L ingegnerla del software paolo macchi ISIS Facchinetti 5 1005 25 Relazione tra fenomeni condivisi e sistema Affermazione prescrittiva su Affermazione prescrittive su propriet descrittiva del D A sistema sistema che NON impongoma osservo Asserzioni prescrittive cl naer en devono essere soddisfatte PAd nel k prescritti
48. enti lo utilizzano La valutazione euristica un metodo detto discount in quanto consente di comprendere in tempi rapidi i principali problemi di usabilit nell interazione con il sistema per esempio assenza o non correttezza dei feedback sulle azioni comprensibilit del linguaggio utilizzato efficacia del supporti alla navigazione Tali risultati possono rappresentare un primo screening delle criticit di interazione dei siti La valutazione euristica un metodo ispettivo ovvero viene applicato da esperti di usabilit Altri metodi prevedono invece il coinvolgimento attivo degli utenti per esempio cognitive walkthrough e valutazione basata su scenari tra essi il pi noto il test di usabilit Il test di usabilit consente di valutare nel dettaglio le performance e le reazioni dell utente nei diversi stadi di sviluppo del sistema tramite l uso dei prototipi e fornisce indicazioni per le modifiche da apportare nelle fasi successive di design redesign Per condurre un test di usabilit bisogna compiere una serie di passi fondamentali come indicato di seguito Definire gli obiettivi del test generici o specifici Definire il campione dei soggetti che partecipano al test Il numero di valutatori influenza 1l numero dei problemi di usabilit individuabili Selezionare test case rappresentativi delle attivit che gli utenti svolgeranno sul sistema Decidere 1 criteri di valutazione dell usabilit qualitativi e quantitativ
49. ftware ha come obiettivo riuscire a sviluppare software in maniera efficace e con costi contenuti cost effective Cos 11 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 Software e Generici Sviluppati per essere venduti ad una vasta gamma di utenti Contribuiscono alla maggior spesa di software e 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 e Problemi della produzione del software e Ciclidi vita del software Analisi e progettazione e Aspetti generali dell analisi e della progettazione e Analisi e progettazione orientata agli oggetti e UML come linguaggio di analisi e progettazione Pattern architetturali e di progettazione e Progettazione dell interfaccia e Documentazione e Testing validazione e debugging Obiettivi e pianificazione del testing Progettazione e valutazione dei casi di test Debugging e Manutenzione tipi e processi di manutenzione software Gesti
50. i Il 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 Capacit di affrontare evoluzione Gestione delle conf IRUFAazioni Ad ex Versione e modifiche e compatibilit tra le versioni e Generalit Risolvere il problema generale Riusabilit Ex Funzione di ordinamento per campi diversi crescente decrescente Pi la soluzione generale pi usabile Ma ovviamente il costo funzione della generalit e della riusabilit Quindi qual il livello a cui fermarsi e Incrementalit Procedere a passi successivi 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 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 A Esercizio come vengono implementati questi punti ad esempio nella costruzione di una automobile Dov la modulartit incrementalit astrazione ecno2 L ingegneria del software paolo macchi acchinetti 13 Il processo di produzione sviluppo del software Il processo di produzione software un insieme di attivit i
51. i Predisporre l ambiente di testing e verificare che il prototipo supporti 1 test case selezionati Eseguire 1l test documentandone lo svolgimento registrazione audio o video appunti scritti log delle interazioni Analizzare 1 risultati Ta definizione dei test case una fase cruciale e anche difficile visto il numero di possibili situazioni Alcuni approcci per questa definizione si basano sui modelli legati al mondo dell intelligenza artificiale Il planning per esempio pi goal oriented e permette una volta definito lo stato finale di ricostruire 1 cammini che portano a quello stato eventualmente definendo anche il punto iniziale In alternativa vi sono approcci basati su event flow sulla definizione cio di test case sulla base della sequenza di azioni che devono essere compiute 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 Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 46 Interfaccia approvata L utente valuta l interfaccia a N v NO PROBLEM il metodo che ha fatto la fortuna di molte aziende medio piccole del nordest SCHEMA PER LA SOLUZIONE DI OGNI PROBLEMA ia Pe LR lee POITO DARGHE LACOLPA A QUALCHEDUNI
52. i 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 gt Java gt modello astratto Qui perdo una serie di elementi ma so cosa ecnoZ L ingegneria del soitware paolo macch acchinetti 12 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 Codice modello con tutti i dettagli gi un astrazione modello a stati ignora dettagli che qui non interssano del codice binario pobi vodu Esempio semplice la lampadina System out printlIn SERVER In ascolto Inizializzazione degli stream BufferedInputStream bin new Lampadina BufferedInputStream client getInputStream in new DatanputStream bin BufferedOutputStream bout new BufferedOutputStream client getOutputStream Bruciata out new DataOutputStream bout Il Ricezione del messaggio proveniente dal client liga ci n String message in readUTF Ovviamente sempre l uomo deve capire cosa astrarre cosa no e Previsione dei cambiament
53. i 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 1 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 1 due approcci Nella pratica spesso i due approcci non sono cos rigidi e c una contaminazione tra 1 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 Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 18 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
54. iabili dobbiamo distinguerlo in e Dinamico gt quando le variabili di stato cambiano valore nel tempo e Statico gt quando le variabili di stato assumono sempre lo stesso valore e Chiuso gt 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 e Aperto gt 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 e Deterministico gt 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 e Probabilistico o Stocastico gt quando ad una stessa sollecitazio
55. iche di controllo J J li Fermo J 3 Specifiche algebriche dominio e operazioni sul dominio J sorts dominio operazioni operations Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 29 La fase di progettazione come 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 Si compone di due fasi diversificazione e convergenza e Durante la diversificazione il progettista acquisice il materiale grezzo del progetto componenti possibilit di realizzazione conoscenze per individuare le possibilit realizzative e Nella fase di convergenza sceglie e combina gli elementi disponibili per arrivare ad un prodotto finale 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 Il progetto deve soddisfare 1 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 Le tecniche di progettazione si basano su tecniche per
56. ie nella fase iniziale del progetto quando ancora mancano sufficienti elementi di N dettaglio ma gi necessario definire budget e piano di lavoro Necessit di aderire a precisi standard nella produzione dei documenti di progetto con il rischio di introdurre una eccessiva burocratizzazione delle attivit Il documento che specifica 1 requisiti non sempre soddisfa le effettive esigenze degli utenti perch spesso gli utenti stessi non sono in grado di conoscere e quindi di descrivere con efficacia tutti 1 requisiti dell applicazione Considerando che questo documento vincola il prodotto da sviluppare la sua rigidit sin all inizio del processo rappresenta un limite piuttosto significativo per la qualit del prodotto finale Vantaggi e limitazioni del modello a cascata La Prototipazione e lo Sviluppo Evolutivo Spesso i requisiti del modello a cascata non sono abbastanza chiari Il cliente stabilisce gli scopi generali del Tecno2 L ingegneria del software paolo macchi ISIS Facchinetti 151005 17 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 1 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
57. ime E il software che sorveglia analizza controlla eventi esterni mentre avvengono Software gestionale Elaborazione di dati aziendali e Software scientifico e per l ingegneria Algoritmi di calcolo intensivo astronomia vulcanologia biologia molecolare terremoti e Software embedded Risiede generalmente in memorie per sola lettura e ha lo scopo di controllare prodotti e sistemi di consumo o Industriali e Software per1 personal computer Elaborazione testi fogli elettronici grafica programmi multimediali Software basato sul Web CGI PHP JSP Software per l intelligenza artificiale Algoritmi non numerici euristici per la risoluzione di problemi complessi ksercizio Elencare 2 applicazioni software per ogni tipologia Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 7 Che cos l ingegneria del software L Ingegneria del Software un insieme di teorie metodi e strumenti per sviluppare software di qualit in maniera professionale L ingegneria del software 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 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
58. ioni che consentono quelle azioni Va infine sottolineato che il concetto di usabilit di un sistema soprattutto pratico l analisi deve fornire linee guida operative per la progettazione Infatti al centro dell usabilit vi la consapevolezza che ogni alternativa di progettazione deve essere valutata il pi presto possibile con gli utenti potenziali del prodotto L obiettivo delle valutazioni assicurare che 1 prodotti a base software Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 45 bd Ne IDU PY siano caratterizzati da tempi di apprendimento dei contenuti rapida esecuzione dei compiti basso tasso di errore facilit di ricordare le istruzioni base alta soddisfazione dell utente Per progettare interfacce caratterizzate da un buon livello di usabilit sono state sviluppate linee guida e standard differenti L ISO 9241 ha definite l usabilit come the extent to which a product can be used by specified users to achieve specified goals with effectiveness efficienty and satisfaction in a specified context of use In questa definizione l efficacia indica l accuratezza e la completezza con cui gli utenti possono raggiungere I loro obiettivi mentre l efficienza riguarda le risorse necessarie per farlo e la soddisfazione si riferisce al comfort e al grado di accettabilit dell esperienza d uso Nielsen di recente ha definito cinque principi fondamentali di usabilit Apprendibi
59. l automa indicare lo stato finale uomo e passeggeri sulla sponda destra indicare gli stati proibiti capra cavolo oppure lupo capra incustoditi determinare se esiste una parola accettata che possa venir generata con una produzione che non passi per alcuno stato proibito e in caso positivo indicare tale produzione Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 7
60. l cui fine lo sviluppo oppure la modifica di un prodotto software Attivit generiche in tutti 1 processi di produzione del software Specifica cosa deve fare il sistema e quali sono i vincoli per la progettazione 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 a nuove esigenze I sistemi software sono intangibili Pertanto necessario documentare e tenere traccia di ci che si sta facendo Il ciclo di vita del software Definisce un modello per il software dalla sua concezione iniziale fino al suo sviluppo completo al suo rilascio alla sua successiva evoluzione fino al suo ritiro Definisce dunque 1l processo attraverso cui il software evolve si parla di software lifecycle o software Process Perch avere un modello 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 produ
61. lassi 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 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 Concetto intuitivo l attributo nome della classe Cliente indica che i clienti hanno un nome Gli 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 informazioni sullo 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 Esempio Nome della classe size Rectangle Attributi visibility Boolean defaultSize Rectangle maxsSize Rectangle ptri Xwindow Qperazioni Displavy Hide Create attachXWindow xwin Xwindow Moreno Marzolla Ingegneria del Software Nota i simboli indicano la visibilit cio se possono essere usati o meno da oggetti di altre classi Molteplicit delle Associazioni Gli estremi di un
62. le attivit tra 1 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 Esempio semplice la lampadina Lampadina Q Accensione Bruciata Moreno Marzolla Ingegneria del Software Yor mimber is dialed Moreno Marzolla ingegneria del Software Lift Person at othe recerrer end rms off Lift recelrer Off hoak conversation Hang up j answered at otherend Hang up Oif hook Dial ringing tone mimber Complete Cecnoz ingegnerta del so tware paolo maccni acchinetti 52 Controllo impianto Deterministiche Non deterministiche Transizioni e attivit La sintassi generale di una etichetta associata ad una transizione 9 lt Evento gt lt Condizione gt lt Azione gt Esegui L azione se si verifica l evento e la condizione vera La sintassi di una attivit pi semplice do lt nome attivit gt Diagrammi di Attivit e Mostra le elaborazioni che internamente avvengono nel sistema in funzione dei suoi cambi di stato Activity Diagram Actor X Syistem Y Descrivono la sequenza delle attivit e supportano un comportamento sia condizionale che parallelo Due costrutti fondamentali Branch diramazione Merge giunzione ecno
63. lesse e suddividendole successivamente in parti pi piccole Eventualmente 1 componenti sono specificati quanto basta per la codifica Top Down Integration Testing REALIZZAZIONE DEI COMPONENTI http sce uhcl edu whiteta sdp subSystemIntegerationTesting htm 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 1 requisiti di ognuna di queste funzioni ed il processo verr ripetuto Queste sotto procedure a comparto Tecno L ingegneria del soltware paolo macchi ISIS Facchinetti 151005 33 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 I a ma LI ui Ha LI T SA li i i g ea iem z F L i i SMI H Boni programmazione top down Vantaggi Il gruppo di programmazione
64. li 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 realizzalnformation hiding un modulo offre all esterno un insieme di funzionalit senza rivelare come sono realizzate e Ogni modulo deve nascondere una decisione ma deve fornire all esterno certe funzionalit e 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 e Ogni modulo ha delle strutture dati private non accessibili se non tramite le funzioni di interfaccia e Viene cos risolto il problema dell accoppiamento i moduli comunicano solamente per mezzo di funzioni di interfaccia e per mezzo dei loro parametri Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 37 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 i
65. lit la facilit di apprendimento delle funzionalit e del comportamento dell applicazione Efficienza il livello di produttivit ottenibile dopo che l utente ha appreso il funzionamento del sistema Memorizzabilit la facilit di ricordare le funzionalit del sistema in modo che l utente casuale possa ritornarvi dopo un periodo di non uso senza aver bisogno di un nuovo periodo di apprendimento Riduzione degli errori la capacit del sistema di prevenire gli errori e di aiutare l utente a non compierne se l utente sbaglia ugualmente deve essere messo in grado di rimediare in modo facile e veloce Soddisfazione dell utente la misura in cui l utente trova il sistema piacevole da usare Lo stesso Nielsen ha anche proposto una valutazione euristica del sistema Essa consente di analizzare le specifiche di un sistema in riferimento a delle euristiche o linee guida ossia 1 principi consolidati di buona progettazione e ergonomia La valutazione euristica consiste in un giudizio da parte degli esperti valutatori sull aderenza o meno dell interfaccia alle linee guida di usabilit Le linee guida basandosi sulle caratteristiche cognitive e comportamentali degli individui durante l interazione con il sistema informativo definiscono e descrivono le propriet di un sistema che possa essere definito usabile Un prodotto usabile quando consente di raggiungere in poco tempo e con buona tolleranza agli errori gli scopi per i quali gli ut
66. lmente 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 ecno2 L ingegneria del software paolo macchi acchinetti 21 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 amp 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 spieghi Per ogni fase citare esplicitamente cosa riceve in ingresso e cosa produce in uscita Soffermarsi 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 spieghi Per ogni fase citare esplicitamente cosa riceve in ingresso e cosa produce in uscita Comparare questo modello con il precedente spiegandone i miglioramenti NB l esposizione deve essere fatta in mod
67. mplementato o moduli per i quali risulta subito chiaro che devono realizzare determinate funzionalit Si confrontano 1 moduli ottenuti con quelli esistenti se si trovano moduli simili o gi realizzati si modifica 1l 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 progetto Nella 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 1 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 p
68. n una attivit Un affermazione generica di cosa deve fare un programma sufficiente per iniziare a scrivere codice I requisiti mutano di continuo ma i cambiamenti si gestiscono facilmente grazie alla flessibilit del software Il solo prodotto di un progetto concluso il programma funzionante L ingegneria del software ci far scrivere un inutile e voluminosa documentazione che inevitabilmente rallenter la cose facilmente automatizzabile Se siamo in ritardo possiamo recuperare aumentando il numero di programmatori Adding manpower to a late project makes it later Fred Brooks se una donna partorisce in 9 mesi due donne lo fanno in 4 mesi e mezzo paradosso della partoriente Costi nel processo di produzione del Software Circa 11 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 1 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 temp
69. ne 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 e Combinatorio gt quando l uscita dipende solo dagli ingressi e non dallo stato interno I sistemi combinatori sono detti anche Sistemi senza memoria e Sequenziale gt quando l uscita dipende sia dagli ingressi che dallo stato interno Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 62 Esistono altre classificazioni piu specifiche e dettagliate Senza entrare in merito a queste classificazioni riportiamo solo alcuni esempi Sistema trascendentale 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 NOTA Il modo di pensare sistemistico ha permesso di u
70. nno un diverso tipo di requisiti con contraddizioni ad esempio o costo qualit o Funzionalit semplicit o Usabilit funzionalit Requisiti e specifiche Qui non parliamo di come piattaforme codici linguaggi ma di cosa e Requisiti cosa richiesto nel Dominio Applicativo tipicamente l utente finale che vive nel D A e Specifiche cosa deve fare il sistema per soddisfare le richieste del Dominio Applicativo Cosa sono 1 requisiti I requisiti sono le caratteristiche che utente e committente desiderano che siano presenti in un prodotto software da realizzare 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 1 requisiti Utente e committente valuteranno il risultato sulla base del fatto che soddisfi o meno 1 requisiti Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 23 Analisi dei requisiti e Il committente esprime una serie di vincoli e Il fornitore formula una o pi ipotesi di soluzione in grado di rispondere in tutto o in parte ai requisiti espressi e 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 Modello H1 Interfaccia Ethemet 100BASE TX Windowse 7 Home Premium Professional Ultimate 1 Sistema operativo Windows
71. nti 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 cfr http cs unibg it scandurra material PINF3_0809 processo pdf e Reazione efficace rapida e adattiva ai cambiamenti e Comunicazione efficace fra tutti gli stakeholder e Assorbimento del cliente nel team di sviluppo e Organizzazione del team che lo ponga in diretto controllo del proprio lavoro Producendo e Consegne incrementali e frequenti di software e 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 1 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 A Il problema La cooperativa Lacoop4u fondata nel 2001 e costituita da 40 soci ognuno dei quali e proprietario di un negozio di 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 fina
72. o necessario per revisionare ed approvare 1 documenti pu essere significativo Responsabilit Etica professionale Non 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 http www acm org about se code Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 9 Il processo di produzione del Software tools per la produzione del software Intro 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 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 1 processi affidabili prevedibili ed efficienti Tutti 1 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 alcune funzioni prim
73. o sintetico rispettando esattamente i punti citati nella successione con cui sono stati espressi Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 272 Analisi e specifica del requisiti cosa Un progetto ha successo se soddisfa 1 requisiti Descrivere male 1 requisiti porta a risultati fallimentari Qui ci occupiamo di definire cosa un sistema debba fare le sue propriet essenziali ed 1 vincoli a cui deve rispondere Intuitivamente un requisito ci che ci aspettiamo dal sistema ci che andiamo a realizzare Un requisito del software un affermazione sul software che riguarda propriet comportamenti vincoli di varia natura E importante scoprire analizzare documentare e verificare 1 requisititi Questa analisi presenta forte interazione con il cliente Definizione e Specifica dei requisiti gt Tecniche per analizzare definire e specificare 1 requisiti dei sistemi software Difficile soddisfare 1 requisisti perch e interpretazione del problema diversa le controparti non sanno esattamente cosa vogliono Scritti mali con modi di esprimersi diversi Fattori politici e organizzativi possono influenzare 1 requisiti del sistema I requisiti sono inevitabilmente soggetti al cambiamento e correggere 1 requisiti traumatico e costoso e diversi stakeholder cio chiunque ha interesse nel progetto committente progetto implementazione Marketing Guadagno ha
74. ocode com Articles 460 aspx 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 e 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 e 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 e 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 ma
75. of bottom up design because the parts are first created and then assembled without regard to how the parts will work in the assembly Wikipedia Top Down Process ss990J4 dn wWopog Top down vs bottom up Alcune parti di questo capitolo sono tratte dal libro Perl Design Patterns Book 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
76. ome era previsto o Are we making the right product e Verificareseilsistema 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 o Are we making the product right Definizioni Errore 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 XX write y ERRORE di editing digitazione DIFETTO causato da un errore gt invece di MALFUNZIONAMENTO gt il valore visualizzato errato Possibile MALFUNZIONAMENTO in esecuzione pu verificarsi o meno dipende dall input ux Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 55 Relazione fra errore difetto e malfunzionamento causa causa errore Difetto Malfunzionamento Standard IEEE per il Testing Standard IEEE 610 12 1990 1 The process of operating a system or component under specified conditi
77. omplementi alla CREATIVIT umana ad esempio con 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 o Permette di rendere la creativit condivisibile e capibile Ad esempio la descrizione formale e la prova formale di un protocollo di comunicazione o 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 e La separazione dei problemi o fondamenale perch oltre un certo livello di complessit non siamo pi in grado di vedere TUTTI 1 dettagli ad es Sistema Operativo O Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 11 E importante capire che noi esser umani NON SIAMO IN GRADO DI PRENDERE IN CONSIDERAZIONE TUTTI DETTAGLI un limite intrinseco alla mente umana ad es Ssitema Operativo Come si fa allora Sottoproblemi Divide et Impera Ai tempi dei romani tale strategia era un mezzo adoperato per governare il territorio 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
78. one della configurazione Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 6 Le caratteristiche del software Il 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 hardware Mentre l industria si dirige sempre pi verso un assemblaggio a componenti la maggior parte del software viene realizzato in modo specifico Curva dei guasti per l hardware Curva dei guasti per il software e E u_u A l Aumento della ireguenza di quasto Moralia inanma a causa di affetti collaterali Madilica Fraquenza di quasto Frequenza di guasto Gura reale b Cura ideale ENR Tempo i Moreno Marzalla ingegneria del Software 17 Moreno Marzolla ingegneria del Software Caratteristiche di un prodotto Software e Mantenibilit Evolvere in rapporto alla modifica di requisiti e Affidabilit Ci si deve poter fidare del prodotto Software Correttezza Robustezza Verificabilit Sicurezza Innoquit Efficienza Non deve sprecare risorse memoria tempo e Usabilit Deve avere interfaccia e documentazione appropriate I diversi tipi di software e Software di sistema Collezione di programmi al servizio di altri programmi compilatori editor strumenti per la gestione di file Software real t
79. ons 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 http www federica unina it ingegneria ingegneria software ii verifica convalida software 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 e Dimostrare al cliente e allo sviluppatore che 11 software soddisfa 1 suoi requisiti Si parla di Test di Convalida e Verificacheil software si comporti adeguatamente usando un insieme di casi di test che riflette l uso previsto e 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 1 malfunzionamenti eseguire un programma al fine di scoprire un errore e Rivelala presenza di errori NON la loro assenza e Un caso di prova valido se ha un alta probabilit di scoprire un errore ancora ignoto e Un test riuscito se ha scoperto un errore prima ignoto non 1l contrario Testing e debugging Testing e debugging sono due
80. ossono 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 1 punti di decisione e 1 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 Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 38
81. pi lunga della riga cosa faccio Potrei avere una soluzione corretta ma non soddisfa l utente word processor 4 Incrementale avere pi bozze sempre pi dettagliate Aggiornare le specifiche in modo incrementale Stili di specifica e Differenti tecniche possibili per descrivere le specifiche Prima caratterizzazione e informali usano tipicamente linguaggi naturali e Semi formali usano notazioni grafiche per cui la semantica non sempre precisamente definita e Formali attraverso modelli matematici J e Non c il meglio e il peggio dipende cosa si vuole descrivere J A Esempio di notazione informale semiformale un sensore su un ascensore Se un sensore non funziona 1l sistema dovrebbe fermare l ascensore in funzione al piani precedenti o successivi L ascensore deve fermarsi se il FELL E sensore del piano selezionato Direction Down and i Pa ProssimaRichiesta y and rileva il passaggio dell ascensore x lt y then Rallentare Motore Er ascencorspiamo x IL Ev_escentormpiano KM and ProssimaRichiesta y and Rif Esempio Ascensore xy then Rallentare Motore J J Seconda caratterizzazione e Operazionali descrizione con una macchina astratta e Descrittive definisce la propriet ecnoZ L ingegneria del soitware paolo macch acchinetti 27 l A Una figura geometrica Ellisse come la descrive il giardiniere operazionale il metodo consiste nel piantare nel terreno i
82. proprio Anche qui il problema limitato solo alla parte specificata 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 Media Fine Aggiorna Somma e cerca Massimo Minimo Inizio Per indice da 1a 11 Aggiorna Somma con elemento considerato Se elemento lt Minimo Sostituisci elemento a Minimo Altrimenti Se elemento gt Massimo Sostituisci elemento a Massimo Fine se Fine se Fine per Fine Il terzo sottoprogramma immediato Calcolo escursione termica Inizio Escursione Massimo Minimo Fine Il quarto sottoprogramma come il secondo prevede una inizializzazione Calcolo scostamento medio Inizio Azzera Somma scostamenti Aggiorna Somma Calcola Media scostamenti Fine Aggiorna Somma scostamenti Inizio Per indice da 0a 11 Se elemento gt Media aritmetica Scostamento elemento Media Altrimenti Scostamento Media elemento Fine se Aggiorna Somma scostamenti con scostamento Fine per Fine Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 40 L ultimo sottoprogramma immediato Comunicazione risultati Inizio Comunica Media Comunica Escursione termica Comunica Scostamento medio Fine Il programma a questo punto interamente svolto Ogni sottoprogramma ha riguardato un solo aspetto dell elaborazione ci rende la stesura
83. r emergere con chiarezza 1 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 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 Il Dizionarietto del Diavolo del DP As spociied in ihe propici nicputi As designed by he senior designa fra dI As product try matuta ttring As installed at iho users st Viu ho user vanted Qualche esempio reale Se i costruttori costruissero come i programmatori programmano il primo picchio che passa potrebbe distruggere la civilt Weinberg Legge di 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 disastro http sunnydav mit edu accidents ArianeSaccidentreport html Il Therac 25 1 Era un dispositivo computerizzato per la radioterapia dei pazienti affetti da cancro Tra giugno 1985 e gennaio 1987 sei pazienti sono stati uccisi o feriti seriamente da dosi eccessive di radiazioni Rspons
84. re capacit e alla vostra indole Mi comunicherete la formazione del vostro gruppo ed eventuali modifiche I Leader e Problem solving determinare 1 fattori tecnici e organizzativi pi Importanti strutturare sistematicamente una soluzione motivare gli sviluppatori e Identit manageriale assumersi la responsabilit del progetto coordinazione del resto del team e Incentivazione ricompensare lo spirito di iniziativa saper rischiare e Influenza e spirito di gruppo Mantenere 1l controllo nelle situazioni critiche relazionarsi bene coi colleghi Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 58 Il team Se vuoi migliorare in modo incrementale sii competitivo se vuoi migliorare in modo esponenziale sii cooperativo Autore ignoto Staff tecnico auto organizzato e Parola d ordine cooperazione Criteri di valutazione e Qualit del progetto sviluppato e Coesione del gruppo RICORDA Cos un progetto software Temporaneo amp Unico e 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 e 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 d
85. resta focalizzato sull obiettivo e Ognuno conosce il proprio compito e Nel momento in cui parte la programmazione non vi sono pi domande e codice semplice da seguire dato che scritto in maniera metodica e con uno scopo preciso Svantaggi e 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 e Tutte le decisioni dipendono dall avvio del progetto ed alcune decisioni non possono essere fatte sulla base del dettaglio delle specifiche Bottom up La progettazione Bottom up parte dal basso e va verso l alto Sui 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 pioccoli pezzi di programma che sono facili 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 Tecno L ingegnerla del software paolo macchi ISIS Facchinetti 5 1005 34 Incoming Call WSDL Interface Top Down Java Interface Java Implementation eci i Building blocks are an example
86. roblema che si era individuato e capito nelle fasi precedenti Si parte dal Documento di Specifica e si cerca di capire COME realizzarlo e 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 1 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 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 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 4 Codifica Implementazione dei vari componenti definiti nel Progetto
87. sa 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 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 L idea consiste nel progettare un sistema come un insieme di oggetti interagenti Ogni oggetto costituito da e uno stato cio una rappresentazione interna nascosta agli altri oggetti information hiding e 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 protocollo dell oggetto Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 41 In particolare e dettagli realizzativi di un oggetto non sono noti all esterno information hiding e Gli oggetti modellano 1 conce
88. scire dai ristretti campi specialistici delle varie scienze e di capire che non sempre 1 sistemi reali ricadono necessariamente nelle divisioni delle varie scienze In particolare 1 sistemi che riguardano l interazione uomo macchina e nello specifico 1 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 1 confini della singola disciplina ed entra nel terreno della interdisciplinariet Automi a stati finiti Gli Automi a Stati Finiti sono usati in informatica da lungo tempo anche in sistemi particolarmente popolari come 1l software per 1 videogiochi e la robotica 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 in modo simile a un grafico di flusso in cui si pu controllare la logica di funzionamento L Automa descrive il sistema in base al solo suo funzionamento senza alcun riferimento alla cosa macchina o altro e al modo con cui realizzata 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 ricevu
89. so di sviluppo software 14 OMO 14 Poirino alain 14 Mod Urar IOE Oera E E E E E E sioni 14 Modeloa ca caa Wella 15 Considerazioni sul modello a CASCA irradia 17 La Prololipazone e lo Sviluppo LOUVO EIA 17 Syluppo inore mentale 1MEraliyO PRO RARO RE RAI 18 Processo asile Usato 11 OPEN SOUTCO ini 21 Analisi e Specifica dei FEQUISILI COST iscriva tann ans senenin Eaa natanti nina EEN linda rara 23 Regulis especie oerni ratori LI 23 Cosa sono i reduisili ilaele 23 Cosa sono le specie ie aeris in n nee rea a e E A aa eere aani 24 VUE RR ROTTE Zi EHI P FAI SPECII e irpini ritieni 28 La fase di progettazione come aailali aa 30 Metodologie p r la PIOSCHAZIONE di SMI 31 LI AE RI 01 0 RR RA RR RO RIA 31 bi Sped eEEro gioia 31 EC AISEGIDIOSCHAZIO Gioia 31 Progettazione top down DOHOMEUpi crrrrrinrraniii alan aaa aaa ia aaiae 32 La Programmazione top down bottom up ii 36 Indipendenza Modiano iaia pro 37 Il primcerpio dellmforination Idrico nani 37 Qual la migliore strategia per lo SVilUppo iiiii 38 Strategia di progetto orientata alle FUNZIONI arresero 38 LA Un esempio di programmazione Top Down funzionale 39 Strategia di propelo orema MOL liana 41 Differenze e analogie tra approccio funzionale e ad oggetti 42 L interfaccia utente miei 43 Resole dorodell Interfa seta Lenza iO Fai INTE a ORLEANS Ra 43 Processo di Proge
90. specifici rendendo pi ordinato l indirizzamento delle varie problematiche Uno dei limiti maggiori di questo approccio che 11 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 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 1 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 basate su una divisione del lavoro accentuata modello adeguato quando i requisiti sono ben compresi e non soggetti a modifiche le fasi avanzano in ordine tipicamente sequenziale Il processo poco efficace rispetto alla evolvibilit Va bene se NON ci saranno cambiamenti futuri ammesso sia possibile Quindi Difficile operare cambiamenti una volta che il processo in corso Pertanto difficile soddisfare cambiamenti nei requisiti da parte del committente grosso limite Il partizionamento in fasi pu apparire arbitrario o artificioso Difficolt a stimare in modo accurato 1 costi e le risorse necessar
91. stemi ignorando come operano al loro interno 3 Disegno delle interfacce a Descrive l interfaccia dei sottosistemi verso altri sottosistemi 4 Disegno dei componenti a Allocarei servizi ai diversi componenti e definire le interfacce di questi componenti 5 Disegno delle strutture dati a Specificare come sono fatte le strutture dati 6 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 modello di progettazione 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 1 sottoproblemi che lo compongono TOP UP DOWN BOTTOM 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 I Top down in maglieria Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 32 La tecnica per fare maglioni top down prevede una laorazione dal collo fino al bordo inferiore ossia dall alto verso il basso senza cu
92. tema da realizzare si presenta logicamente costruito da un insieme di sottosistemi che realizzano 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 di determinare 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 mantenere nascoste all esterno dei moduli vengono presentate solamente le funzionalit richieste opportuno ritornare di nuovo ad una strategia orientata agli oggetti Il progetto viene visto e rivisto pi volte Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 42 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 benissimo quello 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
93. to 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 altre situazioni 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 3 I U S f g dove I l insieme degli ingressi U l insieme delle uscite S l insieme degli stati interni in cui pu trovarsi Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 63 f la funzione che fa passare da uno stato al successivo St f S 19 g la funzione che determina il valore delle uscite U g Sa 1 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 STATE Button Click Open lightagff Stato 0 Ever Msi Power Off IN Power On Button click Close light on ACTION TRANSITION OUT cfr http odet
94. to double i I Prezzolvato double PrezzoGuantit double DateOrdine String CodiceP nodotto String Quantitabiagazzino double Unitaliisura char Catalindine Siring fai t cadiceordine int nome String Yia String Citta String DescrizioneP ro dotto String PrezzoP nodotto double Prezzo vato double Atiribute_3 cint Quantita Minimabiagazzino double COsfruito CodiceFornitore String Moma String Mia Strina gt Citta String http www giullodestri 1t doc ingsw D04_GuidaEsame pdf Diagrammi relativi agli aspetti dinamici di un sistema Fino a qui abbiamo visto 1 diagrammi che rappresentano la struttura statica di una Architettura Software Occorre per anche caratterizzarne il comportamento dinamico Diagrammi di Sequenza e Mostral ordinamento temporale dei messaggi scambiati tra gli elemrnti del sistema I Diagrammi di Sequenza sono utilizzati per mostrare quali comunicazioni vengono effettuate tra oggetti Tecno L ingegnerla del software paolo macchi ISIS Facchinetti 5 1005 51 Telefono Telefono 1 nuova lelefonatal 1 1 linea disponibile 2 numero 081555555550 2 2 riproduci tono di chiamala0 chiamante 2 1 nproduci squillon Diagrammi di Stato e Mostra 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 del
95. tradurre 11 modello in progetto 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 concegnato 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 AI termine del progetto va sempre prevista una revisione formale che lo riesamini nel suo complesso La revisione non deve perdersi nei dettagli sintattici 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 o Utilizzare notazioni grafiche formali o intuitive per descrivere le componenti del progetto o Ripetere il processo per ciascuna astrazione individuata fino a quando il progetto espresso in termini primitivi In pratica procedere a liv
96. trice di transizione Stati Eventi Azioni del tipo Stato Evento Evento 1 Evento 2 Stato 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 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 1 Il succedersi delle stagioni con gli effetti su un albero Stati e Inverno e Primavera e Autunno e Estate con la relativa successione Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 64 Eventi e il 21 marzo l evento che fa transitare da Inverno a Primavera e il 21 giugno da Primavera a Esate e cos via Azioni e L albero mette i fiori L albero mette 1 frutti L albero lascia cadere le foglie L albero va in letargo Non difficile realizzare un grafo e la tabella delle transizioni Esempio 2 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 Automi riconoscitori http terzablst altervista org automiriconoscitori html Si tratta di automi particolari aventi una o pi entrate ma sicuramente un unica uscita L unica uscita
97. ttazione dell Intertaceta siririi iii 44 NO ili E E E e irta 44 L interazione uomo macchina linee guida e standard 0rrrrrrrrrrrrececeseeeseseseceeseneseeseceeeeseneneseseceeneneneeseeeeeseneneseceeeeene 45 OZ CI FO IR RIE 46 Soluzioni perla progettazione i miri 48 LITE 48 Tecno2 L ingegneria del software paolo macchi ISIS Facchinetti 151005 2 OT ERRORE 48 Diagrammi relativi agli aspetti statici di un sistema 49 Diagrammi relativi agli aspetti dinamici di un sistema i SI Collaudo del softWaf 3 s0cssiczricszissaranasinizizianena uiciaianivanpezinianaldennanginasa dani varangiiinianaiennatpnaiaiataiciruaselanda Aana aa atalanta 55 Strategie Problemi LiImitazi nl siria 56 A E E a E E A A A N EA A EA A A EEE E EA 58 Lo P O e E E T E E A NT 58 N a T E O 58 RR RARI OO CIOTTI 58 Ibid iaia i olii 58 lilla 59 40 CR IERI 59 Cos can procio Solare ira rientri rie E riabilitato beta 59 Toni pal d PrOSIIO nni eee 59 PIO SONA irene gli 59 Progelare con BU TAS iii Ina 60 DUPO AS T e E A E E E E 60 AOC A a RR IE NA A A E NE E 61 Progettare una mensola porta 0gg6111 iiiiii aaa 61 Progettare la ciccia del WOSHO CANG ici III inasar naseiani Ea dirian IT te 61 Prosa po RIPA A A LO 61 Proe Ra E E 61 ADDO E oars AEE EA E N E ii 62 Ee E E AE nia ini 62 OOO RE RETE 63 PSI n 70 Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005
98. tti del dominio sono 1 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 e 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 he comunicano 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 Un oggetto noto all esterno come entit attive e la rappresentazione dei dati chiamata di un modulo vista come la richiesta ad un a o oggetto di eseguire una sua funzionalit e la condivisione di informazioni sullo stato devono 88 8 essere prese prima Questo tende ad aumentare l accoppiamento del sistema e quindi a ridurre la modificabilit dello stesso Buona coesione Buona coesione coesione intorno alle funzionalit La progettazione ad oggetti porta a coesione attorno ad entit 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 sis
99. turale anche con l ausilio di tabelle e grafici e Le specifiche formali si basano su formalismi matematici sono espresse in un linguaggio con sintassi e semantica definite formalmente studenti d13 units it Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 24 Specifiche tecniche ASUS G51J ASUS M60J Windows Vista Home Premium Autentico con possibilit di upgrade a Windows 7 16 HD 1366x768 retroilluminato a LED con tecnologia Color Shine NVIDIA GeForce GTX 240M con 1GB DDR3 VRAM 1 TB 2x 50066 2 5 SATA 5400rpm Supporto Dual HDD Combo Blu ray reader e DYD Super Multi Combo Blu ray reader e DYD Super Multi Dual Layer Dual Layer Intel WiFi Link 5100 802 11 n Bluetooth Intek WiFi Link 5100 802 11 n Bluetooth 2 1 EDR Gigabit LAN 42 1 EDR Gigabit LAN 2 xX 2W Altoparlanti stereo Altec Lansing con 2 x 2W Altoparlanti stereo Altec Lansing supporto EAX Advanced HD 4 0 certificati Dolby 2 Home Theatre Video Camera Integrata da 2M pixel Integrata da 2M pixel Dimensionie 3 5mm x 265mm x 34 3 40 6mm 3 5kg 392mm x 27 7mm x 32 24 44 _6mm 3 3kg peso con batteria da 6 celle con con batteria da 6 celle A Esempio parcheggio controllato se 10 utente devo entrare in un parcheggio ci che mi interessa che la sbarra si alzi Non mi intgeressa se l apertura della sbarra controllata o da un controllo software Ci un requisito Invece ci che deve fare il sist
100. uovo e poco sperimentato Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 20 Processo agile usato in open source Nel mondo Open Source difficile controllare persone e processi Ecco perch sono nati 1 cosiddetti processi agili tra i pi noti eXtreme Programming che sono processi di tipo iterativo Il manifesto agile http www agilemanifesto org iso it con i suoi principi http www agilemanifesto org iso it principles html recita Manifesto per lo Sviluppo Agile di Software 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 strumenti Il software funzionante pi che la documentazione esaustiva La collaborazione col cliente pi che la negoziazione dei contratti Rispondere 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 requisiti e alla progettazione I processi agili in realt sono molto disciplinati essendo basati su pratiche rigorose e misurabili e sulla trasparenza degli avanzamenti lavoro e dei risultati nei confronti di tutti 1 partecipa
101. 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 11 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 attivita 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 Fasi del modello a cascata Studio di fattibilit Defnizione del problema Analisi dei requisiti _ Speci fca dei requisi Modellazione Specifica dell architetana Progettazione Specifica di progetto Integrazione e collaudo di sistema fosco
102. ve ch sere soddisfatte Asserzioni fenomeni condivisi Ti valgono nel dominio applicativo Segnale tessera valida sal le 1001 ua Br Veicolo autorizzato E parcheggio non esaurito teRasha Rena E sii Segnale apri parcheggio non esaurito E sensore ingresso attivo o varco si apre Segnale apri varco varco aperto descrizione del dominio ex corpi cadono quando il corpo non trattenuto cade Allora possiamo anche dire che la relazione generale specifiche requisiti specifiche Specifica d M a Come voglio E F MEER TE NOn PSAaUr Ii tO 4 Requisiti propriet E sensore ingresso attivo che Il sistema Propriet apri varca agisca inon controllo di dominio i Al utenete interessa CHE VARCO SI APRA requisito effetto che voglio che il sistema abbia Il progettista si occuper solo delle specifiche Specifiche 1 Precise e chiare cio Dettagliate senza tralasciare elementi importanti Esempio di ambiguit Tecno L mgegneria del software paolo macchi ISIS Facchinetti 5 1005 26 Word processor Ambigua selezione in modo conscutivo non mi chiarisce la forma dell area da utilizzare non definisce alcune possibilit ex CTRL SHIFT 2 Completezza definire tutti 1 termini glossario interna inoltre documentare 1 requisiti necessari esterna 3 Consistente garantisce di essere soddisfatta in modo univoco Esempio inconsistente le parole sono indivisibili Se
103. zione dei beni Il modello consente di pianificare le attivita e le risorse necessarie di prevedere e controllare 1 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 Modelli di processo Processi di produzione del Software insieme coerente di attivit per la specifica il progetto l implementazione la verifica di sistemi software Un modello di processo una rappresentazione astratta di un processo Descrive un processo da una particolare prospettiva Ci sono modelli di processo generici Tecno L ingegneria del software paolo macchi ISIS Facchinetti 151005 14 A cascata 1l primo che risale agli anni 60 o Fasi distinte di specifica e sviluppo Modello evolutivo o Specifica e sviluppo interagiscono prototipi Modello trasformazionale o Un sistema matematico trasformato formalmente in una implementazione Sviluppo basato sul riutilizzo o Il sistema ottenuto combinando componenti esistenti Noi ci soffermeremo sul Modello a Cascata e sul Modello Evolutivo Il primo perch storicamente 1l pi rilevante e perch da esso si evolvono 1 successivi Il secondo perch quello attualmente pi

Tecno2 - L`ingegneria del software - Paolo Macchi

Contents

Download Pdf Manuals

Related Search

Related Contents