Ingegneria del software PDF

Preview

Summary

INGEGNERIA DEL SOFTWARESlide Concetti Base DEFINIZIONE 1): Applicazione di un approccio sistematico, disciplinato e quantificabile nello sviluppo, funzionamento e manutenzione del software. IEEEDEFINIZIONE 2):Creazione di software multiversione da parte di piu operatori. PARNASpagina 2PAROLE CHIAVE:...

Description

INGEGNERIA DEL SOFTWARE Slide Concetti Base DEFINIZIONE 1): Applicazione di un approccio sistematico, disciplinato e quantificabile nello sviluppo, funzionamento e manutenzione del software. IEEE DEFINIZIONE 2):Creazione di software multiversione da parte di piu operatori. PARNAS pagina 2 PAROLE CHIAVE: sistemi software complessi, team di ingegneri (attività di gruppo), modifiche durante la loro vita (ogni tipo: aggiunta,eliminazione,correzione,miglioramenti) , progettazione di componenti software, forma definita intorno anni settanta, strumenti e competenze matematiche, caratteristiche prodotto != caratteristiche progetto, programma complesso ⊂ software complesso (inteso come sottoinsieme, quindi caso particolare), linguaggi di programmazione (algoritmi e strutture dati), richiesta → specifica (inteso come “richiesta trasformata in specifica”) da pagina 3 a 5 inclusi MODELLO 1) Modello a cascata (Waterfall) l’unica azione possibile è passare dalla fase A alla fase B come una cascata trasferendo i risultati alla fase successiva a quella corrente.

A

Ciclo di vita del software (esempio a fianco, pagina 6) FASE 1) i costi ed i benefici della realizzazione del sistema, documentare I requisiti, partecipazione dell’utente, del team e di specialisti, progettazione test

B

FASE 2) Si scompone in progettazione Architetturale di alto livello che vede I componenti software ad alto livello e la progettaizone di dettaglio che vede I moduli come sottoinsieme dei componenti a basso livello Moduli ⊂ Componente FASE 3) Sviluppo del codice implementando I risultati precedenti, creazione dei moduli da passare alla fase successiva FASE 4) Costituzione del intero sistematico FASE 5) Sistema finito, da qui in poi inizia il periodo di supporto al software da pagina 5 a pagina 9

Slide qualità del software PAROLE CHIAVE: prodotto ⊂ progetto, possibile modificare il prodotto software anziché l’intero progetto (Duttilità), fabbricazione e implementazione sono funzione del costo finale (cioè i primi due parametri sono importanti per capire il costo finale), prodotto software → processo (inteso come “realizzato da”), caratteristiche e qualità del processo influenzano il prodotto, processo di sviluppo rilascia artefatti (documento di specifica) Da pagina 1 a 3 inclusi CARATTERISTICHE: Duttilità, costo finale QUALITA’: interne (riguardano gli sviluppatori e quindi la struttura del software) ed esterne (direttamente visibili dall’utente) INTERNE: 1) Correttezza cioè proprietà matematica che verificano il soddisfacimento dei requisiti funzionali e non funzionali (sussiste un’equivalenza fra software e specifica richiesta, le specifiche si assumono note, pagina 4) 2) Affidabilità cioè Probabilità P che il software si comporti come atteso in un intervallo di tempo ( correttezza ⊂ Affidabilità) , pagina 5 3) Robustezza cioè la probabilità 1-P (non a caso P) che il software si comporti bene anche al di fuori dei suoi contesti (cioè se l’affidabilità ragiona precisamente sulle specifiche, qui andiamo fuori dalle specifiche), pagina 6 4)Prestazioni cioè uso delle risorse, pagina 7 5)Verificabilità cioè quanto è difficile approvare la correttezza di un software, pagina 9 6)Manutenibilità cioè portare supporto dopo la consegna del software (correzioni,miglioramenti,aggiunte,eliminazioni) , pagina 10 7)Riparabilità cioè la capacità di un software di essere riparato senza troppi sforzi, pagina 11 8)Evolvibilità cioè la capacità che nel ciclo di vita di un software, pagina 12 9)Riusabilità cioè la capacità di riusare parti del software in altri software, pagina 13 10)Produttività cioè è una qualità del processo di sviluppo che indica l’efficienza e prestazioni di sviluppo, pagina 17 ESTERNE: 1)Usabilità cioè facilità d’uso per l’utente (per quanto riguarda la grafica del sotware oppure per configurazioni varie), pagina 8 2)Portabilità cioè avere la possibilità di usare un software in ambienti diversi (linux,mac,windows,Android,iOS…), pagina 14 3)Comprensibilità cioè quanto è facile capire il software, pagina 15 4)Interoperabilità cioè comunicazione tra sistemi diversi, pagina 16 5) Tempestività cioè la capacità di emanare rilasci del software completo in tempi brevi (ostacolo principale:richieste dell’utente), pagina 18 6)Visibilità cioè la documentazione del progetto in tutte le sue fasi, pagina 20

Slide Principi del software PAROLE CHIAVE: principi base di metodi – tecniche – metodologie – strumenti, principi applicati al processo e al prodotto, metodi cioè regole da applicare all’esecuzione di un’attività, tecniche ⊂ metodi cioè sono metodi particolari (lato meccanico e applicativo), una metodologia è la fusione tra metodi e tecniche, gli strumenti contengono tutte le metodologie da poter adottare, i principi sono alla base dell’ingegneria del software e delle metodologie, i principi sono applicati al processo e al prodotto Da pagina 1 a 3 inclusi PRINCIPI: Modularità 1) cioè la suddivisione in moduli del software per semplificare il processo di produzione (divide et impera, top-down, bottom-up, basso accoppiamento cioè i moduli devono essere collegati ma poco tra di loro in maniera tale che ogni modulo sia un modulo cooperante con gli altri ma non dipendente), da pagina 9 a 11 inclusi Rigore e formalità 2) Il rigore serve per ottenere un software affidabile, verificabile, è possibile controllare i costi e garantire la correttezza, formalità → rigore (inteso come “il livello massimo di rigore”), al tempo stesso c’è da rispettare il patto tra sviluppatore e cliente cioè il cliente deve essere in gradi di capire che tipo di garanzie ha senza perdersi nel formalismo spesso complicato da comprendere, può essere applicato a progettazione specifica e verifica. Pagina 5 e 6 Separazione degli interessi 3) Bisogna saper gestire la progettazione completa del software separando le parti da realizzare in vari aspetti cioè suddividere il lavoro in base al tempo, ai moduli da generare, alle qualità da garantire, ai problemi da risolvere e all’implementazione del codice, pagina 7 e 8 Astrazione 4) è un sottoinsieme della separazione degli interessi cioè significa prescindere da dettagli e vedere il tutto ad alto livello, si può ricavare un modello che può essere formale che aiuta a effettuare test prima ancora che il modulo esista, maggiore concentrazione sul problema da risolvere, da pagina 12 a 15 inclusi Anticipazione del cambiamento 5) cioè favorisce l’evolvibilità e la riusabilità del software, vuole significare essere sempre pronti ai cambiamenti del corso di sviluppo del software, pagina 16 Generalità 6) cioè rappresenta la capacità di vedere il problema generale che proviene dal applicazione di un problema preciso, pagina 17 Incrementalità 7) cioè lo sviluppo di parti intermedie provviste di testing del software completo, pagina 18 Caso di studio compilatore da pagina 19

Slide Processo di produzione PAROLE CHIAVE: ciclo di vita, elenco attività coinvolte, ordine delle attività, relazioni tra attività, creazione di stadi che durano un determinato tempo e condizioni che ci portano da stadio a stadio, il processo influenza qualità prodotti, modo ordinato di procedere, svantaggi “black box” senza processi cioè dai requisiti ottengo il prodotto passando per un processo “monothread” ad unico rilascio con progressi invisibili Pagina 2, da 5 a 7 inclusi ATTIVITA’: Fattibilità 1) Illustrazione tramite documento contenente scenari e soluzioni con alternative per sviluppare il progetto. Pagina 9 Requisiti 2) cioè sono gli obbiettivi da raggiungere, le qualità da soddisfare, vedere come si approccia il progetto alla vita reale, prendere la visione di chi userà questo progetto (stackholder), vedere dominio applicativo, principi usati: Separazione interessi, Modularità, Astrazione. Pagina 10 e 11 Documento Specifica 3) contiene tutte le informazioni necessarie per usare il progetto, specifica i domini che il progetto incorpora cioè chi può usarlo, che entità usa e che relazioni ci sono tra le entità, è approvato dagli stackholder, dice le qualità da raggiungere, Da pagina 13 a 15 inclusi Modularizzazione Orizzontale 4) modello dei dati (ER,classDiagram), funzioni eseguibili (useCaseDiagram, Diagramma flusso), disciplina esecuzione funzioni (reti di petri, activityDiagram) pagina 12 Requisiti funzionali 5) cioè le cose che fa il prodotto in notazione formale o semiformale, pagina 14 Requisiti non funzionali: Affidabilita’, accuratezza, prestazioni, Interfaccia tra sistema e utente, Limiti operativi, limiti fisici, portabilita’, pagina 14 Requisiti del processo di sviluppo e manutenzione: Procedure per il controllo della qualita’, Priorita’ di sviluppo tra le funzioni, Possibili cambiamenti del sistema requisiti MUST: non possono mancare, sono la base requisiti SHOULD: sono di arricchimento ma non di base requisiti MAY: sono facoltativi pagina 15 Definizione architettura software 3) produzione documento di specifica di progetto, elenca componenti, interfacce e relative relazioni tra esse, elenca le motivazioni di progetto, pagina 16 Produzione e test dei codici 4) cioè qui si produce tutto il codice di progetto sviluppando singolarmente in moduli, pagina 17

Integrazione e test del sistema 5) cioè si effettuano ulteriori test sui codici precedenti, assemblando tutti i componenti in un unico sistema, pagina 18 Rilascio, installazione e manutenzione 6) cioè è la fase finale del progetto in termini di consegna ma non di vita, pagina 19 PROCESSI: Code & fix 1) è il più semplice che consiste nello scrivere codice e man mano che va avanti correggerlo. Risulta anche quello più scomodo per grandi software, poca gestione dei progetti. Nel periodo che più vantava questo utilizzo, la crisi del software venne riconosciuta. Da qui nacque l’ingegneria del software, pagina 3 e 4 modelli generali ) la qualità del prodotto è tutelata dal processo di produzione e durante quest’ultimo si controllano i livelli di qualità, modo ordinato di procedere, senza modelli si procede con una black box, processo monothread , principio Do It Twice cioè fallo due volte il progetto perché la prima volta è di test, Alcuni prevedono dei rilasci intermedi autosufficienti ma non completi appositamente per studiare meglio il sistema, altri prevedono che il primo progetto sviluppato sia di test e il secondo progetto sia quello vero e proprio. Pagina 6,7,25,26, Waterfall 2) cioè il modello utilizzato nelle pagine precedenti. Risulta sequenziale, e trasporta risultati da una fase all’altra. Non prevede risposte da parte delle fasi successive che tornano indietro, è anche il più semplice ma più lungo e prevede un unico rilascio. Prevede anche che praticamente ogni parte di sviluppo del software sia costruita in un solo colpo. Passati da A a B il prodotto finale in B non può cambiare. Analisi dei requisiti e documenti di specifica sono prodotti sequenzialmente e globalmente, quindi il tutto rende difficile operare quando i sistemi sono grandi, si parte con informazioni limitate, da Pagina 20 a 23 Waterfall con feedback 2) è lo stesso di prima ma prevede delle risposte che tornano indietro cioè da una fase posso passare a quella precedente. Passo da A a B, poi da B a C ma posso anche tornare a B o ad A. Nonostante ho questo passaggio in più ho problemi con progetti grandi, pagina 23

A

B

C

Modello a spirale 3) è un modello che consiste nel dividere tutta la progettazione in vari step che sono completati una volta che la spirale compie un giro nei 4 quadranti a partire dall’origine di un semplice piano cartesiano. Ogni ciclo è un rilascio incrementale. I 4 quadranti sono visti come fasi: individuazione di obbiettivi, alternative e vincoli per il primo quadrante, valutazione delle alternative e dei rischi che si corrono nel secondo quadrante, sviluppo del software nel terzo quadrante, pianificazioni fasi successive come quarto quadrante. Pagina 27 e 28

Modello RUP 4) è un modello che utilizza UML, trasforma la visione orientata agli oggetti verso un sistema iterativo e incrementale, ogni attività raggiunge una milestone mentre un’attività è chiamata workflow le attività principali sono di valutazione iniziale del progetto che hanno come input gli use case, elaborazione dei casi d’uso e delle architetture, costruzione del codice e test , poi il rilascio finale. Un dettaglio particolare di questo modello è l’uso di un linguaggio grafico come UML. Da pagina 34 a 36 inclusi

Slide Intro UML

PAROLE CHIAVE: notazioni grafiche, descrizione e progetti di sistemi software, standard controllato dal Object Management group, adatte al paradigma orientato agli oggetti, potrebbe servire come

abbozzo del sistema software senza entrare troppo nei particolari per discutere le migliori soluzioni analizzando aspetti come i componenti con i loro stati e azioni, si può anche usare come modello di implementazione, utile per attraversare il progetto con un’occhiata, può essere mirato a diversi aspetti del progetto descrivendolo completamente. Da pagina 2 a 6 inclusi DIAGRAMMI: Casi d’uso 1) interazioni tra utenti e sistema UML 1 Classi 2) classi cioè la modellazione delle idee, loro caratteristiche e relazioni UML 1 Sequenza 3) interazioni tra oggetti nei scenari più comuni, con enfasi sulla sequenza UML 1 Oggetti 4) configurazione esemplificativa di istanze delle classi, rappresenta la concretizzazione delle idee UML 1 Package 5) struttura gerarchica a tempo di compilazione e organizzazione software UML 1 Deployment 6) distribuzione artefatti in diversi nodi del sistema mostrando diversi livelli di astrazione, illustra la disposizione fisica del sistema UML 1 Macchine a stati 7) reazioni di un oggetto agli eventi UML 1 Attivita’ 8) flusso di lavoro e funzionamento casi d’uso UML 1 Comunicazione 9) interazione tra oggetti con enfasi sui collegamenti UML 1 Struttura composita 10) scomposizione di una classe a runtime UML 2 Componenti 11) struttura dei componenti e loro connessioni UML 1 Interazione generale 12) fusione di un diagramma di sequenza ed uno di attivita’ UML 2 Temporizzazione 13) interazione tra oggetti con enfasi sul tempo UML 2 Pagina 7,8,9

Slide casi d’uso

PAROLE CHIAVE: scenario è un’interazione divisa in passi fra utente e sistema che sono sottoinsiemi dei casi d’uso che sono lo scopo dell’utente, lo scenario è una possibile esecuzione del caso d’uso, un utente (non per forza fisico, può avere altre nature) è detto attore, tra attore e scenari possono esserci relazioni multiple e singole, estensione significa che il caso d’uso è opzionale che si verifichi mentre inclusione significa che è obbligatorio che si utilizzi, pre-condizione inizializza il caso d’uso, garanzia descrive cosa si ottiene in questo punto del diagramma, trigger specifica quale azione ha fatto entrare in gioco il caso d’uso, sea level sono i casi d’uso tra attore principale e sistema, fish level sono i casi d’uso implicati dal sea-level, kite level sono i casi d’uso dedicati al business. Da pagina 2 a pagina 4 inclusi, pagina 6 e 12 ELEMENTI: Omino stilizzato 1) attore Linea continua senza freccia 2) associazione caso d’uso – attore (inteso come “interagisce”) Le cardinalità sono 1:n Attore-Caso e 1:n Caso-Attore cioè (1 caso è associato ad 1 o più attori) e (1 attore è associato a 1 o più casi) ellisse 3) caso d’uso freccia tratteggiata con freccia così “>” cioè V rovesciata senza chiudere il triangolo 4) Relazione di inclusione oppure estensione, dipende dalla parola inserita tra >. La freccia parte dal caso o attore che estende verso il caso o attore che è esteso (attenzione la presenza > e è necessaria affinché sia di estensione o inclusione, altrimenti è dipendenza)

freccia continua con freccia così “|>” cioè chiusa a triangolo vuoto 5) generalizzazione Cioè l’elemento a fine freccia specializza un elemento a inizio freccia Pagina 7,8,10

Slide ClassDiagram PAROLE CHIAVE: accorpa informazioni come il nome della classe, attributi, proprietà e operazioni (“metodo” se si tratta di implementazione altrimenti procedura), caratteristica=operazioni+proprietà, vincoli tra gli oggetti (ad esempio visibilità o tipi di oggetti da rispettare), proprietà=campi classe (in Java ad esempio) rappresentati come attributi (nel rettangolo se sono semplici) o come associazioni (con frecce esterne se complicate), in base all’idea che si vuole realizzare cambia la struttura dati e il metodo che restituisce la proprietà, Liskov=Ovunque ci si attende un’istanza dell’entità più generica deve essere possibile utilizzare, senza alterare il corretto funzionamento del sistema, un’istanza di quella più specifica, le proprietà a livello implementativo hanno significati diversi a seconda del linguaggio usato, le relazioni in UML sono riferite alla fine della freccia (la cardinalità messa alla fine della freccia indica la cardinalità dell’entità a inizio freccia), se un’operazione non modifica lo stato=query, generalizzazione=da classe generale a classe particolare, ELEMENTI: Attributo1

Classe

Classe + Attributi public - attributi private # attributi protected ~ attributi package

Attributo2

Operazioni

Classe1

1

*

Classe2

Significa Classe1 ha un numero qualunque di istanze Classe2 mentre Classe2 ha a forza 1 istanza di Classe1

Classe

ClasseGener

ClasseSpec

Nota

La classe figlia specializza la classe Padre Generalizzazione

Classe dipendente

Classe indipendente

Unidirezionale Dipendenza è inteso “L’oggetto indipendente che è a fine freccia, l’oggetto dipendente a inizio freccia” Call=A invoca B Create=A crea istanze B Derive=A deriva da B Istantiate=A istanza di B Permit=A accede B Refine=A ha un certo valore semantico rispetto B

Classe Realizzata

Realizzazione Interfaccia da realizzare

Substitute=A può sostituire B Trace=A tiene traccia di B Use=A richiede B Formattazione attributo: public|private|protected|package nomeAttributo : tipoAttributo molteplicità = valoreDefautSeNonSpecifico {proprietà aggiuntive} Formattazione operazioni: public|private|protected|package nomeMetodo (parametri in input/output) : tipoRitornato {proprietà}

Slide ClassDiagram Avanzato PAROLE CHIAVE: static si mette se l’operazione/attributo è riferito alla classe e non alle sue istanze (esempio costante di nepero/metodi utilità, sottolineata se static), attributi possono essere derivati da altri, l’aggregazione è l’esistenza di una certa classe indipendentemente dall’esistenza dell’altra seppur siano legate (motore-aggregato-auto, esistono motori, esistono auto, anche in maniera separata, rombo vuoto), la composizione è un’aggregazione forte e la presenza di una classe è fondamentale per la vita di tutto il blocco di classi legate dalla composizione (cuoio, aria compressa, senza aria compressa il pallone cioè cuoio+aria non esiste, rombo pieno), classi astratte indicate corsivo, interfacce indicate , esistono interfacce che possono servire per fornire qualcosa (interfacce create da noi per esempio Figure2D che serve per area e perimetro, simbolo di un pallino) oppure interfacce obbligatorie per avere dei servizi da poter fornire (comparable, serializzable… simbolo di aggancio con un pallino), l’associazione qualificata indica un vincolo da rispettare delle istanze create (indicata da rettangolino sulla linea associativa, il vincolo è l’unica istanza possibile delle classi dall’altra parte dell’associazione=Una linea d’ordine per quel prodotto), classi associative arricchiscono il contenuto dell’associazione tra classi (massimo un’istanza di classe associativa per associazione), una quadratino tratteggiato in alto su una classe con una lettera rappresenta lo schema delle classi parametriche, possono prendere valori prefissati, classe attiva controlla il proprio thread, un’associazione ripiegata sulla stessa classe è riflessiva. ELEMENTI: composizione Classe Metodo statico Attributo statico Attributo composto=attr1+attr2

ClasseParte

ClasseTutto

ClasseTutto

ClasseTutto aggregazione

A

I...