Riassunti di Ingegneria del Software PDF

 Riassunti di INGEGNERIA DEL SOFTWARE...

 Riassunti di INGEGNERIA DEL SOFTWARE DI D’ANGELO CARMINE Indice 1 Introduzione............................................................................................................................... 6 1.1 Definizioni.................................................................................................................................. 6 1.1.1 Cosa è il software................................................................................................................. 6 1.1.2 Prodotti generici vs Prodotti specifici.................................................................................. 6 1.1.3 Programma vs prodotto........................................................................................................ 6 1.1.4 Costi..................................................................................................................................... 6 1.1.5 Manutenzione....................................................................................................................... 6 1.1.6 Software engineering........................................................................................................... 6 1.1.7 Differenza tra software engineering e computer science..................................................... 6 1.1.8 Natura del software.............................................................................................................. 6 1.2 Fondamenti dell’ingegneria del software................................................................................... 7 1.2.1 Principi................................................................................................................................. 7 1.2.2 Metodi e metodologie.......................................................................................................... 7 1.2.3 Strumenti, procedure e paradigmi........................................................................................ 7 1.3 Qualità del software.................................................................................................................... 8 2 Cicli di vita del software............................................................................................................ 8 2.1 Modello di ciclo di vita del software (CVS)............................................................................... 8 2.2 Modello a cascata........................................................................................................................ 9 2.2.1 Organizzazione sequenziale: fasi alte del processo............................................................. 9 2.2.2 Organizzazione sequenziale: fasi basse del processo.......................................................... 9 2.2.3 Pro e contro del modello a cascata....................................................................................... 9 2.3 Modello (V&V) e Retroazione (Feedback).............................................................................. 10 2.4 Modello a V.............................................................................................................................. 10 2.5 Modello trasformazionale......................................................................................................... 11 2.6 Modello di sviluppo basato sul riuso........................................................................................ 11 2.6.1 Full Reuse Model............................................................................................................... 11 2.7 Modello evolutivo (a prototipazione)....................................................................................... 11 2.8 Modello incrementale............................................................................................................... 12 2.9 Modello a spirale...................................................................................................................... 12 2.10 Modelli e valutazione dei rischi.............................................................................................. 13 2.12 Scopo dell’ingegneria del software......................................................................................... 14 3 Project management................................................................................................................ 14 3.1 Team di sviluppo...................................................................................................................... 14 3.2 Stesura del piano del progetto................................................................................................... 14 3.3 Grafo delle attività (PERT)....................................................................................................... 15 1 3.4 Management dei rischi.............................................................................................................. 15 3.4.1 Identificazione................................................................................................................... 15 3.4.2 Analisi dei rischi................................................................................................................ 16 3.4.3 Pianificazione dei rischi..................................................................................................... 16 3.4.4 Monitoraggio dei rischi...................................................................................................... 16 4 UML (Unified Modeling Language)....................................................................................... 16 4.1 Diagrammi dei casi d’uso (use case diagrams)......................................................................... 16 4.2 Diagrammi di classi (class diagrams)....................................................................................... 17 4.2.1 Classi in UML.................................................................................................................... 17 4.2.2 Attributi.............................................................................................................................. 17 4.2.2.1 Attributi derivati........................................................................................................ 17 4.2.2.2 Attributi ridondanti......................................................................................................... 18 4.2.3 Operazioni (Metodi/Funzioni)...................................................................................... 18 4.2.4 Responsibility.................................................................................................................... 18 4.2.5 Proprietà attributi e operazioni.......................................................................................... 18 4.2.5.1 Visibilità.......................................................................................................................... 18 4.2.5.2 Molteplicità..................................................................................................................... 19 4.2.5.3 Specifica attributi............................................................................................................ 19 4.2.5.3 Specifica operazioni........................................................................................................ 19 4.2.6 Legami e associazioni........................................................................................................ 19 4.2.6.1 Molteplicità delle associazioni........................................................................................ 20 4.2.7 Ruoli................................................................................................................................... 20 4.2.7.1 Interface specifier........................................................................................................... 20 4.2.8 Associazione...................................................................................................................... 20 4.2.8.1 Classi associative............................................................................................................ 21 4.2.9 Aggregazione..................................................................................................................... 21 4.2.10 Composizione.................................................................................................................. 21 4.2.11 Generalizzazione (o ereditarietà)..................................................................................... 21 4.2.11.1 Ereditarietà multipla..................................................................................................... 21 4.2.12 Classi astratte................................................................................................................... 22 4.2.13 Root, leef elementi polimorfici........................................................................................ 22 4.2.14 Gerarchia di classi............................................................................................................ 22 4.2.15 Dependency..................................................................................................................... 22 4.2.16 Realization....................................................................................................................... 23 4.2.16 Interfacce (definizione).................................................................................................... 23 4.2.17 Modelli dinamici con UML............................................................................................. 23 4.3 Interaction diagram................................................................................................................... 23 4.3.1 Iterazioni e messaggi......................................................................................................... 24 4.4 Diagrammi sequenziali (sequence diagrams)........................................................................... 24 4.4.1 Iterazioni (ricorrenze)........................................................................................................ 25 4.4.2 Cicli e condizioni............................................................................................................... 25 4.4.3 Auto-chiamata.................................................................................................................... 26 4.4.4 Esprimere vincoli sul tempo di risposta............................................................................. 26 4.4.5 Messaggi e azioni............................................................................................................... 26 4.5 Diagramma a stati (state chart)................................................................................................. 26 4.5.1 Elementi grafici dello state diagram.................................................................................. 27 4.5.2 Caratteristiche dello stato................................................................................................... 28 4.5.3 Caratteristiche delle transizioni......................................................................................... 28 2  4.5.4 Attributi (opzionali: evento [condizione]/azione).............................................................. 28 4.5.5 Stato composto................................................................................................................... 28 4.6 Diagrammi delle attività (activity diagrams)............................................................................ 29 4.6.1 Elementi grafici.................................................................................................................. 30 4.6.2 Swimlanes.......................................................................................................................... 30 4.7 Raggruppamento (packages)..................................................................................................... 31 5 Raccolta dei requisiti (requirements elicitation)................................................................... 31 5.1 Classificazione dei requisiti...................................................................................................... 32 5.1.1 Requisiti funzionali............................................................................................................ 32 5.1.2 Requisiti non funzionali..................................................................................................... 32 5.2 Validazione dei requisiti........................................................................................................... 32 5.2.1 Tracciabilità....................................................................................................................... 33 5.2.2 Greenfield engineering, re-engineering, interface engineering......................................... 33 5.3 Attività della raccolta dei requisiti............................................................................................ 33 5.3.1 Identificare gli attori.......................................................................................................... 34 5.3.2 Identificare gli scenari....................................................................................................... 34 5.3.3 Identificare i casi d’uso...................................................................................................... 34 5.3.4 Raffinare i casi d’uso......................................................................................................... 35 5.3.5 Identificare le relazioni tra attori e casi d’uso.................................................................... 35 5.3.6 Identificare gli oggetti partecipanti.................................................................................... 35 5.3.7 Identificare i requisiti non funzionali................................................................................. 36 5.4 Gestire la raccolta dei requisiti................................................................................................. 37 6 Analisi dei requisiti.................................................................................................................. 38 6.1 Concetti dell’analisi.................................................................................................................. 38 6.1.1 Il modello ad oggetti.......................................................................................................... 38 6.1.2 Il modello dinamico........................................................................................................... 38 6.1.3 Generalizzazione e specializzazione.................................................................................. 39 6.1.4 Entity, Boundary (oggetti frontiera) e Control object........................................................ 39 6.1.5 Ambiguità.......................................................................................................................... 39 6.2 Attività dell’analisi (trasformare un caso d’uso in oggetti)...................................................... 39 6.2.1 Notazioni............................................................................................................................ 40 6.2.2 Identificare gli oggetti entity.............................................................................................. 40 6.2.3 Identificare gli oggetti boundary........................................................................................ 41 6.2.4 Identificare gli oggetti controllo........................................................................................ 41 6.2.5 Mappare casi d’uso in oggetti con sequence diagrams...................................................... 42 6.2.6 Identificare le associazioni................................................................................................. 42 6.2.7 Identificare le aggregazioni............................................................................................... 43 6.2.8 Identificare gli attributi...................................................................................................... 43 6.2.9 Modellare il comportamento e gli stati di ogni oggetto..................................................... 43 6.2.10 Rivedere il modello dell’analisi....................................................................................... 43 7 System design........................................................................................................................... 44 7.1 Scopi criteri e architetture......................................................................................................... 44 7.2 Identificare gli obiettivi di design............................................................................................. 44 7.3 Decomposizione del sistema in sottosistemi............................................................................ 45 7.3.1 Accoppiamento (coupling)................................................................................................ 45 7.3.2 Coesione e Coupling.......................................................................................................... 46 7.3.3 Divisione del sistema con i layer....................................................................................... 46 7.3.4 Divisione del sistema con le partizioni.............................................................................. 46 3  7.3.5 Sottosistemi e classi........................................................................................................... 47 7.3.6 Servizi e interfacce di sottosistemi.................................................................................... 47 7.3.7 Macchina virtuale (Dijkstra).............................................................................................. 47 7.3.7.1 Architettura chiusa (opaque layering)............................................................................. 47 7.3.7.2 Architettura aperta (Trasparent layering)....................................................................... 48 7.3.7.3 Vantaggi e svantaggi delle architetture chiuse............................................................... 48 7.3.8 Basic Layer pattern............................................................................................................ 48 7.4 Architetture software................................................................................................................ 48 7.4.1 Repository.......................................................................................................................... 48 7.4.1.1 Vantaggi e svantaggi....................................................................................................... 48 7.4.2 Model/View/Control (MVC)............................................................................................. 49 7.4.3 Client-Server...................................................................................................................... 49 7.4.4 Peer-To-Peer...................................................................................................................... 49 7.4.5 Three-Tier.......................................................................................................................... 49 7.4.6 Architetture a flusso di dati (pipeline)............................................................................... 50 7.4.7 Considerazioni finali.......................................................................................................... 50 7.4.8 Euristiche per scegliere le componenti.............................................................................. 50 7.5 Descrizione delle attività del System Design........................................................................... 50 7.5.1 UML Deployment Diagram............................................................................................... 51 7.5.2 Mappare i sottosistemi su piattaforme e processori........................................................... 51 7.5.3 Identificare e memorizzare i dati persistenti...................................................................... 52 7.5.4 Stabilire i controlli di accesso............................................................................................ 53 7.5.5 Progettare il flusso di controllo globale............................................................................. 53 7.5.6 Identificare le condizioni limite......................................................................................... 54 7.5.7 Rivedere il modello del system design.............................................................................. 54 7.5.8 Gestione del system design................................................................................................ 54 8 Object design............................................................................................................................ 56 8.1 Concetti di riuso........................................................................................................................ 56 8.1.1 Oggetti di applicazione e oggetti di soluzione................................................................... 56 8.1.2 Ereditarietà di specifica ed ereditarietà di implementazione............................................. 56 8.1.3 Delegazione....................................................................................................................... 57 8.1.4 Il principio di sostituzione di Liskov................................................................................. 57 8.1.5 Delegazione ed ereditarietà nei design pattern.................................................................. 57 8.2 Attività del riuso (selezionare i design pattern e le componenti)............................................. 57 8.2.1 Classificazione dei design pattern...................................................................................... 58 8.2.2 Pattern Strutturali............................................................................................................... 58 8.2.2.1 Composite pattern........................................................................................................... 58 8.2.2.2 Facade Pattern................................................................................................................. 59 8.2.2.3 Adapter Pattern............................................................................................................... 60 8.2.2.4 Bridge Pattern................................................................................................................. 61 8.2.2.5 Proxy Pattern................................................................................................................... 62 8.2.3 Pattern comportamentali.................................................................................................... 62 8.2.3.1 Observer Pattern............................................................................................................. 62 8.2.4 Pattern Creazionali............................................................................................................. 63 8.2.4.1 Abstract Factory.............................................................................................................. 63 8.2.5 Suggerimenti e Note su utilizzo design pattern................................................................. 64 8.2.6 MVC.................................................................................................................................. 64 8.2.7 Identificare e migliorare i framework di applicazione....................................................... 65 4 8.3 Valutare il riuso........................................................................................................................ 65 8.4 Specificare le interfacce dei servizi.......................................................................................... 66 8.4.1 Tipologie di sviluppatori.................................................................................................... 66 8.4.2 Specificare le firme............................................................................................................ 66 8.4.3 Aggiungere contratti (precondizioni, postcondizioni, invarianti)...................................... 66 8.5 Documentare l’Object Design.................................................................................................. 68 9 Mappare il modello nel codice................................................................................................ 68 9.1 Concetti di mapping.................................................................................................................. 68 9.1.1 Trasformazioni................................................................................................................... 68 9.2 Attività del mapping................................................................................................................. 72 9.2.1 Ottimizzare il modello di Object Design........................................................................... 72 9.2.2 Mappare associazioni in collezioni e riferimenti............................................................... 73 9.2.3 Mappare i contratti in eccezioni......................................................................................... 74 9.2.4 Mappare il modello di classi in uno schema di memorizzazione...................................... 75 9.3 Responsabilità........................................................................................................................... 76 9.4 Gestire l’implementazione........................................................................................................ 76 10 Testing..................................................................................................................................... 77 10.1 Overview................................................................................................................................. 77 10.2 Concetti di testing................................................................................................................... 78 10.2.1 Test case........................................................................................................................... 79 10.2.2 Correzioni........................................................................................................................ 80 10.3 Attività di testing.................................................................................................................... 80 10.3.1 Component inspection..................................................................................................... 81 10.3.2 Managing testing............................................................................................................. 81 10.3.3 Documentazione di testing............................................................................................... 81 10.3.4 Usability testing............................................................................................................... 82 10.3.4 Unit testing....................................................................................................................... 82 10.3.5 Integration testing............................................................................................................ 86 10.3.6 System testing.................................................................................................................. 87 11 SCRUM................................................................................................................................... 88 11 Ruoli....................................................................................................................................... 89 11.1.1 Il Team Scrum................................................................................................................. 89 11.1.2 Il Product Owner.............................................................................................................. 89 11.1.3 Team di sviluppo............................................................................................................. 89 11.1.4 Scrum Master................................................................................................................... 90 11.1.5 Ruoli ausiliari................................................................................................................... 90 11.2 Cerimonie............................................................................................................................ 90 11.2.1 Sprint................................................................................................................................ 90 11.2.2 Sprint planning meeting................................................................................................... 91 11.2.3 Daily Scrum meeting....................................................................................................... 91 11.2.4 Sprint Review.................................................................................................................. 91 11.2.5 Sprint Retrospective......................................................................................................... 92 11.3 Artefatti............................................................................................................................... 92 11.3.1 Product backlog............................................................................................................... 92 11.3.2 Sprint backlog.................................................................................................................. 92 11.3.3 Burn down charts............................................................................................................. 92 5 1 Introduzione 1.1 Definizioni 1.1.1 Cosa è il software Il software non è solo un insieme di linee di codice ma comprende anche tutta la documentazione, i case test e i manuali. 1.1.2 Prodotti generici vs Prodotti specifici I prodotti generici sono dei software prodotti da aziende e utilizzati da un ampio bacino di utenza diversificato. I prodotti specifici sono software sviluppati ad hoc per uno specifico cliente, visionato dallo stesso. Il costo dei prodotti generici è maggiore rispetto a quello dei prodotti specifici. 1.1.3 Programma vs prodotto Un programma è una semplice applicazione sviluppata, testata e usata dallo stesso sviluppatore. Il prodotto software viene sviluppato per terzi, è un software industriale che ha un costo di circa 10 volte superiore ad un normale programma. e deve essere corredato di documentazione, manuali e case test. 1.1.4 Costi Il costo del software viene calcolato in base alle ore di lavoro, il software e hardware utilizzato e altre risorse di supporto. Il costo della manutenzione è superiore a quello di produzione. 1.1.5 Manutenzione Il software dopo il suo rilascio, specie se lo stesso ha una vita lunga, ha bisogno di alcune fasi di manutenzione. Per manutenzione intendiamo sia la correzione di eventuali bug, sia l’estensione/modifica di alcune caratteristiche. Il costo della manutenzione è più elevato rispetto a quello di produzione. Abbiamo tre tipi di manutenzione:  Correttiva: eliminazione di difetti  Effettiva: adattamento a nuovi ambienti.  Evolutiva: miglioramenti e nuove funzionalità 1.1.6 Software engineering Disciplina che cerca di fornire le regole per il processo di produzione del software. Lo scopo dell’ingegneria del software è di pianificare, progettare, sviluppare il software tramite lavoro di gruppo. È possibile che vengono rilasciate più versioni del prodotto software. Tale attività ha senso per progetti di grosse dimensioni e di notevole complessità ove si rende necessaria la pianificazione. 1.1.7 Differenza tra software engineering e computer science Mentre la computer science si occupa di creare e ottimizzare algoritmi e si occupa degli aspetti teorici dell’informatica, il software engineering si occupa della pianificazione e della progettazione con la finalità di ottenere un prodotto software. 1.1.8 Natura del software  Intangibile: infatti un prodotto software che creiamo non può essere toccato o visto ameno che di creazione di interfacci grafiche. 6   Malleabile: un software può essere modificato, ma potrebbero derivarne gravi problemi.  Ad alta intensità di lavoro umano: la maggior parte del lavoro nella creazione del software è ancora fatta dall’uomo.  Spesso costruito ad hoc invece che assemblato: si creano ogni volta nuove parti di codice invece di riutilizzare quelle già create. 1.2 Fondamenti dell’ingegneria del software L’ingegneria del software si occupa principalmente di tre aspetti fondamentali: i principi, i metodi, le metodologie e gli strumenti. 1.2.1 Principi 1. Rigore e formalità 2. Affrontare separatamente le varie problematiche dell’attività 3. Modularità (divide-et-impera) 4. Anticipazione del cambiamento (scalabilità) 5. Generalità (tentare di risolvere il problema nel suo caso generale) 6. Incrementalità (lavorare a fasi di sviluppo, ognuna delle quali viene terminata con il rilascio di una release, anche se piccola). 1.2.2 Metodi e metodologie Un metodo è una particolare procedimento per risolvere problemi specifici, mentre la metodologia à un’insieme di principi e metodi che serve per garantire la correttezza e l’efficacia della soluzione al problema. 1.2.3 Strumenti, procedure e paradigmi Uno strumento è un artefatto che viene usato per fare qualcosa in modo migliore. Una procedura è una combinazione di strumenti e metodi finalizzati alla realizzazione di un prodotto. Processo: una particolare metodologia operativa che nella tecnica definisce le singole operazioni fondamentali per ottenere un prodotto industriale. Processo software: un metodo per sviluppare del software, cioè un insieme organizzativo di attività che sovrintendono alla costruzione del prodotto da parte del team di sviluppo usando metodi, metodologie e strumenti. È suddiviso in varie fasi secondo uno schema di riferimento (ciclo di vita del software). È descritto da un modello (informale, semi-formale, formale). Processo creazione software: il processo attraverso il quale le esigenze degli utenti sono tradotte in un prodotto software. Il processo prevede la traduzione delle esigenze degli utenti in requisiti software, la trasformazione dei requisiti software in progettazione, l'implementazione della progettazione in codice, la verifica del codice e, a volte, l'installazione e la verifica del software per l'uso operativo.  Upper-CASE: Strumenti che supportano le attività delle fasi di analisi e specifica dei requisiti e progettazione di un processo software. Includono editor grafici per sviluppare modelli di sistema, dizionari dei dati per gestire entità del progetto.  Lower-CASE: Strumenti che supportano le attività delle fasi finali del processo, come programming, testing e debugging. Includono generatori di graphical UI per la costruzione d’interfacce utente, debuggers per supportare la ricerca di program fault, traduttori automatici per generare nuove versioni di un programma. 7 1.3 Qualità del software La qualità può essere riferita sia al prodotto che al processo applicato per ottenere il risultato finale. Un particolare modello di qualità (modello di McCall) dice che la qualità si basa sui seguenti tre aspetti principali: 1. Revisione: manutenibilità, flessibilità e verificabilità (deve rispettare i requisiti del cliente) 2. Transizione: portabilità, riusabilità, interoperabilità (capacità del sistema di interagire con altri sistemi esistenti) 3. Operatività: correttezza (conformità dello stesso rispetto ai requisiti), affidabilità, efficienza (tempo di risposta o uso della memoria), usabilità, integrità (capacità di sopportare attacchi alla sicurezza). 2 Cicli di vita del software Un processo software è un insieme organizzato di attività finalizzate ad ottenere il prodotto da parte di un team di sviluppo utilizzando metodo, tecniche, metodologie e strumenti. Il processo viene suddiviso in fasi in base ad uno schema di riferimento (ciclo di vita del software). 2.1 Modello di ciclo di vita del software (CVS) È una caratterizzazione descrittiva o prescrittivi di come un sistema software viene sviluppato. I modelli CVS devono avere le seguenti caratteristiche: 1. Descrizione dell’organizzazione del lavoro nella software-house. 2. Linee guida per pianificare, dimensionare il personale, assegnare budget, schedulare e gestire. 3. Definizione e scrittura dei manuali d’uso e diagrammi vari. 4. Determinazione e classificazione dei metodi e strumenti più adatti alle attività da svolgere. Le fasi principali di un qualsiasi CVS sono le seguenti: 1. Definizione (si occupa del cosa). Determinazione dei requisiti, informazioni da elaborare, comportamento del sistema, criteri di validazione, vincoli progettuali. 2. Sviluppo (si occupa del come) Definizione del progetto, dell’architettura software, traduzione del progetto nel linguaggio di programmazione, collaudi. 3. Manutenzione (si occupa delle modifiche) Miglioramenti, correzioni, prevenzione, adattamenti. 8 2.2 Modello a cascata Definisce che il processo segua una progressione sequenziale di fasi senza ricicli, al fine di controllare meglio tempi e costi. Inoltre definisce e separa le varie fasi e attività del processo in modo da minimizzare la sovrapposizione tra di esse. Ad ogni fase viene prodotto un semilavorato con la relativa documentazione e lo stesso viene passato alla fase successiva (milestore). I prodotti ottenuti da una fase non possono essere modificati durante il processo di elaborazione delle fasi successive. 2.2.1 Organizzazione sequenziale: fasi alte del processo  Studio di fattibilità: Effettua una valutazione preliminare dei costi e dei requisiti in collaborazione con il committente. L’obiettivo è quello di decidere la fattibilità del progetto, valutarne i costi, i tempi necessari e le modalità di sviluppo. Output: documento di fattibilità.  Analisi e specifica dei requisiti: Vengono analizzate le necessità dell’utente e del dominio d’applicazione del problema. Output: documento di specifica dei requisiti.  Progettazione: Viene definita la struttura del software e il sistema viene scomposto in componenti e moduli. Output: definizione dei linguaggi e formalismi. 2.2.2 Organizzazione sequenziale: fasi basse del processo  Programmazione e test di unità: Ogni modulo viene codificato nel linguaggio e testato separatamente dagli altri.  Integrazione e test di sistema: I moduli vengono integrati tra loro e vengono testate le loro interazioni. Viene rilasciata una beta release (release esterna) oppure una alpha release (release interna) per testare al meglio il sistema.  Deployment: Rilascio del prodotto al cliente.  Manutenzione: Gestione dell’evoluzione del software. 2.2.3 Pro e contro del modello a cascata Pro  Facile da comprendere e applicare Contro  L’interazione con il cliente avviene solo all’inizio e alla fine del ciclo.  I requisiti dell’utente vengono scoperti solo alla fine.  Se il prodotto non ha soddisfatto tutti i requisiti, alla fine del ciclo, è necessario iniziare daccapo tutto il processo. Rischi:  Soltanto alla fine del progetto il nostro cliente può giudicare il progetto e quindi decidere dei 9  cambiamenti.  Fino al termine del progetto non c’è comunicazione con il cliente. 2.3 Modello (V&V) e Retroazione (Feedback) Uguale al modello a cascata, vengono applicati i ricicli, ovvero al completamento di ogni fase viene fatta una verifica ed è possibile tornare alla fase precedente nel caso la stessa non verifica le aspettative. Verification: stiamo costruendo il prodotto nel modo corretto? Rispetto alle specifiche definite precedentemente? Validation: stiamo costruendo il giusto prodotto? Cioè giusto per il nostro cliente? 2.4 Modello a V È come il modello a cascata, la sua caratteristica è che mette in correlazione alcune frasi basse con le fasi precedenti:  quando si fa testing di unità e integrazione si avrà bisogno del progetto di dettaglio;  quando si verifica la conformità del testing di sistema si ha bisogno del progetto di sistema;  Infine per la validazione dei requisiti del testing di accettazione si ha bisogno di Analisi e specifica dei requisiti. Visto che le attività di destra sono collegate con quelle di sinistra se si trova un errore in una fase di destra si riesegue il pezzo della V collegato. 10 2.5 Modello trasformazionale Basato su un modello matematico che viene trasformato da una rappresentazione formale ad un’altra. Questo modello comporta problemi nel personale in quanto non è facile trovare persone con le conoscenze giuste per poterlo implementare. Tale modello può essere utilizzato con altri modelli per migliorare il processo di sviluppo di sistemi critici, soprattutto quelli in cui la sicurezza è molto importante. Richiede una conoscenza molto approfondita delle proprie tecniche e molta esperienza nell’applicazione della tecnica. Rende difficile specificare formalmente aspetti come le interfacce. Si hanno pochi esempi di applicazione per sistemi complessi. 2.6 Modello di sviluppo basato sul riuso È previsto un repository dove vengono depositate le componenti sviluppate durante le fasi del ciclo di vita. Le componenti vengono prese dal repository e riutilizzate quando necessario. Questo modello è particolarmente usato per sviluppare software in linguaggi Object Oriented. 2.6.1 Full Reuse Model Prevede repository di componenti riusabili a diversi livelli di astrazione, prodotti durante le diverse fasi del ciclo di vita (specifiche, progetti, codice, test case, ecc.). Durante lo sviluppo di un nuovo sistema avvengono: - il riuso di componenti esistenti. - il popolamento delle repository con nuove componenti. 2.7 Modello evolutivo (a prototipazione) In questo modello il cliente è parte integrate del processo di sviluppo del prodotto. Il modello evolutivo si basa su due tipologie di sviluppo basate sui prototipi:  Prototipazione evolutiva (esplorativa) Si inizia a sviluppare le parti del sistema che sono già ben specificate aggiungendo nuove caratteristiche secondo le necessità fornite dal cliente man mano. Lo sviluppo dovrebbe avviarsi con la parte dei requisiti meglio compresa. I pro sono che si può usare per sistemi di piccole dimensioni, e per sistemi con vita limitata. I contro sono che se si effettuano troppe modifiche non si avanza mai nella fase successiva, se vengono apportate molte modifiche il progetto potrebbe non avere più una buona struttura.  Prototipo usa e getta (throw-away) 11  Lo scopo di questo tipo di prototipazione è quello di identificare meglio le specifiche richieste dall’utente sviluppando dei prototipi che sono funzionanti. Non appena il prototipo è stato verificato da parte del cliente o da parte degli sviluppatori può essere buttato via. Abbiamo poi altri due tipi di prototipazione:  Mock-ups: produzione completa dell’interfaccia utente. Consente di definire con completezza e senza ambiguità i requisiti (si può, già in questa fase, definire il manuale di utente).  Breadboards: implementazione di sottoinsieme di funzionalità critiche del SS, non nel senso della fattibilità ma in quello dei vincoli pesanti che sono posti nel funzionamento del SS (carichi elevati, tempo di risposta, …), senza le interfacce utente. Produce feedbacks su come implementare la funzionalità (in pratica si cerca di conscere prima di garantire). Questo modello si può applicare anche a quello a cascata, ma porta diversi problemi come la perdità della visibilità del processo, spesso il prodotto finito è scarsamente strutturato, si perde la visibilità del processo da parte del management. È applicabile su sistemi interattivi di taglia medio-piccola e sistemi con ciclo di vita medio-piccola. 2.8 Modello incrementale Utilizzato per la progettazione di grandi software che richiedono tempi ristretti. Vengono rilasciate delle release funzionanti (deliverables) anche se non soddisfano pienamente i requisiti del cliente. Vi sono due tipi di modelli incrementali:  Modello ad implementazione incrementale Le fasi alte del modello a cascata vengono realizzate e portate a termine, il software viene finito, testato e rilasciato ma non soddisfa tutte le aspettative richieste dall’utente. Le funzionalità non incluse vengono comunque implementate e aggiunte in tempi diversi. Con questo tipo di modello diventa fondamentale la parte di integrazione tra sottosistemi.  Modello a sviluppo e consegna incrementale È un particolare modello a cascata in cui ad ogni fase viene applicato il modello ad implementazione incrementale e successivamente le singole fasi vengono sviluppate e integrate con il sistema esistente. Il sistema viene sviluppato seguendo le normali fasi e ad ogni fase l’output viene consegnato al cliente. Vantaggio Possibilità di anticipare da subito delle funzionalità al committente:  Ciascun incremento corrisponde al rilascio di una parte delle funzionalità  I requisiti a più alta priorità per il committente vengono rilasciati per prima  Minore rischio di un completo fallimento del progetto Testing più esaustivo:  I rilasci iniziali agiscono come prototipi e consentono di individuare i requisiti per i successivi incrementi  I servizi a più alta priorità sono anche quelli che vengono maggiormente testati 2.9 Modello a spirale Il processo è visto come una spirale dove ogni ciclo viene diviso in quattro fasi:  Determinazione degli obiettivi della fase  Identificazione e riduzione dei rischi, valutazione delle alternative 12  Sviluppo e verifica della fase  Pianificazione della fase successiva Una caratteristica importante di questo modello è il fatto che i rischi vengono presi seriamente in considerazione e che ogni fine ciclo produce una deliverables. In un certo senso può essere visto come un modello a cascata iterato più volte.  Vantaggi: Rende esplicita la gestione dei rischi, focalizza l’attenzione sul riuso, determina errori in fasi iniziali, aiuta a considerare gli aspetti della qualità e integra sviluppo e manutenzione.  Svantaggi: Richiede un aumento nei tempi di sviluppo, delle persone con capacità di identificare i rischi, una gestione maggiore del team di sviluppo e quindi anche un costo maggiore. 2.10 Modelli e valutazione dei rischi Il modello a cascata genera alti rischi su un progetto mai sviluppato (greenfield engineering) e bassi rischi nello sviluppo di applicazioni familiari con tecnologie già note. Nel modello a prototipazione si hanno bassi rischi nelle nuove applicazioni, alti rischi per la mancanza di un processo definito e visibile. Nel modello trasformazionale si hanno alti rischi a causa delle tecnologie coinvolte e delle professionalità richieste. 2.11 Dodici regole dell’extreme programming: 1. Progettare con il cliente; 2. Test funzionali e unitari; 3. Refactoring (riscrivere il codice senza alterarne le funzionalità esterne); 4. Progettare al minimo (solo l’indispensabile); 5. Descrivere il sistema con una metafora, anche per la descrizione formale (cioè qualcosa che ricorda una struttura chiara del sistema); 6. Proprietà del codice collettiva (contribuisce alla stesura chiunque sia coinvolto nel progetto); 7. Scegliere ed utilizzare un preciso standard di scrittura del codice; 8. Integrare continuamente i cambiamenti al codice; 9. Il cliente deve essere presente e disponibile a verificare (sono consigliate riunioni settimanali, costanti feedback); 10. Open Workspace; 11. 40 ore di lavoro settimanali; 12. Pair Programming (due programmatori lavorano insieme su un solo computer). Gli obiettivi dell’extreme programming sono l’aiutare la produttività e qualità dei prodotti software. 13 2.12 Scopo dell’ingegneria del software - Migliorare la qualità del prodotto e del processo software - Portabilità su sistemi legacy - Eterogeneità - Velocità di sviluppo 3 Project management Il project management racchiude le attività necessarie per assicurare che un progetto software venga sviluppato rispettando le scadenze e gli standard. Le entità fisiche che prendono parte al project management sono: 1. Buiness manager: definiscono i termini economici del progetto 2. Project manager: panificano, motivano, organizzano e controllano lo sviluppo, stimano il costo del progetto, selezionano il team di sviluppo, stendono i rapporti e le presentazioni. 3. Practitioners: hanno competenze tecniche per realizzare il sistema 4. Customers (clienti): specificano i requisiti del software da sviluppare 5. End users (utenti): gli utenti che interagiscono con il sistema 3.1 Team di sviluppo Esistono vari tipi di team di sviluppo qui di seguito indicati: - Democratico decentralizzato: Assenza di un leader permanente (possono esistere dei leader a rotazione), consenso di gruppo, organizzazione orizzontale. Vantaggi: individuazione degli errori, adatto a problemi difficili Svantaggi: difficile da implementare, non è scalabile. - Controllato decentralizzato: Vi è un leader che controlla il lavoro e assegna i problemi ai gruppi a lui sottesi. I sotto gruppi hanno un leader e sono composti di 2 a 5 persone. I leader dei sottogruppi possono comunicare tra loro come anche i membri dei sottogruppi possono comunicare in maniere orizzontale. - Controllato centralizzato: Vi è un leader che decide sulle soluzioni e l’organizzazione dei gruppi. Ogni gruppo ha un proprio leader che assegna e controlla il lavoro dei componenti. I leader dei gruppi non comunicano tra loro ma possono comunicare solo con il loro capo. I membri dei gruppi non comunicano tra loro ma solo con il capo gruppo. 3.2 Stesura del piano del progetto - Introduzione: Viene definita una descrizione di massima del progetto, gli elementi che vengono consegnati con le rispettive date di consegne e vengono pianificati eventuali cambiamenti. - Organizzazione del progetto: Vengono definite le relazioni tra le varie fasi del progetto, la sua struttura organizzativa, le interazioni con entità esterne, le responsabilità di progetto (le principali funzioni e chi sono i responsabili). - Processi gestionali: Si definiscono gli obiettivi e le priorità, le assunzioni, le dipendenze, i vincoli, i rischi con i relativi meccanismi di monitoraggio, pianificazione dello staff. - Processi tecnici: Vanno specificati i sistemi di calcolo, i metodi di sviluppo, la struttura del team, il piano di documentazione del software e viene pianificata la gestione della qualità. - Pianificazione del lavoro, delle risorse umane e del budget: Il progetto viene diviso in task (attività) e a ciascuno assegnata una priorità, le dipendenze, le risorse necessarie e i costi. Le attività devono essere organizzate in modo da produrre risultati valutabili dal management. I 14  risultati possono essere milestone o deliverables; il primo rappresenta il punto finale di un’attività di processo, il secondo è un risultato fornito al cliente. Ogni task è un’unità atomica definita specificando: nome e descrizione del lavoro da svolgere, precondizioni per poter avviare il lavoro, risultato atteso, rischi. I vari task vanno organizzati in modo da ottimizzare la concorrenza e minimizzare la forza lavoro. Lo scopo è quello di minimizzare la dipendenza tra le mansioni per evitare ritardi dovuti al completamento di altre attività. Le attività del progetto vengono divise in task che sono caratterizzati dai tempi di inizio e fine, una descrizione, le precondizioni di partenza, i rischi possibili ed i risultati attesi. 3.3 Grafo delle attività (PERT) Mostra la suddivisione del lavoro in attività evidenziando le dipendenze e il cammino. Figura 1 Cammino critico del grafo della attività ES1 EF2 LS3 LF4 Tabella 1 Tempi relativi alle attività 3.4 Management dei rischi Il management dei rischi identifica i rischi possibili e cerca di pianificare per minimizzare il loro effetto sul progetto, pianifica i rischi e li monitorizza. 3.4.1 Identificazione I rischi da identificare sono di vari tipi tra cui: rischi tecnologici, rischi delle risorse umane, rischi organizzativi, rischi nei tools, rischi relativi ai requisiti, rischi di stima/sottostima. Le tipologie di rischi sono le seguenti: - Tecnologici: Alcune tecnologie di supporto (database, componenti esterne) non sono abbastanza validi come ci aspettavamo. 1 ES (earliest start time) tempo minimo di inizio dell’attività a partire dal minimo tempo in cui terminano le attività precedenti (ovvero il valore massimo degli EF precedenti). 2 EF (earliest finish time) dato ES è il minimo tempo in cui l’attività può finire. 3 LS (latest start time) dato LF e la durata del task quale è il giorno massimo in cui deve iniziare per evitare ritardo nei task che dipendono da lui. 4 LF (latest finish time) il giorno massimo in cui quel task può finire senza portare ritardi ai successivi (ovvero il valore minimo tra gli LS dei successivi) 15 - Risorse umane:Non è possibile reclutare staff con la competenza richiesta oppure non è possibile fare formazione allo staff. - Organizzativi: Cambi nella struttura organizzativa possono causare ritardi o nello sviluppo del progetto. - Strumenti: Ad esempio il codice/documentazione prodotto con un determinato strumento non è abbastanza efficiente. - Requisiti: Cambiamenti nei requisiti richiedono una revisione del progetto già sviluppato. - Stima: Il tempo richiesto, la dimensione del progetto sono stati sottostimati. 3.4.2 Analisi dei rischi Ad ogni rischio va assegnata una probabilità che esso si verifichi e vanno valutati gli effetti dello stesso che possono essere: catastrofici, seri, tollerabili, insignificanti. 3.4.3 Pianificazione dei rischi Viene considerato ciascun rischio e viene sviluppata una strategia per risolverlo. Le strategie che possiamo prendere possono essere: - Evitare i rischi con una prevenzione - Minimizzare i rischi - Gestire i rischi con un piano di contingenza per evitarli 3.4.4 Monitoraggio dei rischi Ogni rischio viene regolarmente valutato e viene verificato se è diventato meno o più probabile, inoltre i suoi aspetti vanno discussi con il management per valutare meglio i provvedimenti da adottare. 4 UML (Unified Modeling Language) Il modello UML può essere visto gerarchicamente come un Sistema diviso in uno o più modelli a sua volta divisi in una o più viste. Lo scopo dei modelli UML è quello di semplificare l’astrazione di un progetto software e nascondere i dettagli non necessari alla comprensione della struttura generale. Prima di visionare i vari tipi di diagrammi, UML definisce alcune convenzioni. I nomi sottolineati delineano le istanze, mentre nomi non sottolineati denotano tipi (o classi), i diagrammi sono dei grafi, i nodi sono le entità e gli archi sono le interazioni tra di essi, gli attori rappresentano le entità esterne che interagiscono con il sistema. Esistono vari tipi di diagrammi UML qui di seguito descritti: 4.1 Diagrammi dei casi d’uso (use case diagrams) Serve a rappresentare l’interazione del sistema con uno o più attori e descrive tutti i vari casi possibili. Ha un nome univoco, degli attori partecipanti (almeno 1), una o più condizioni di entrata e di uscita, un flusso di eventi e delle eventuali condizioni eccezionali. Tra le entità di un use-case diagram si possono avere varie relazioni rappresentate dagli archi con la freccia rivolta verso l’entità. Le relazioni possono essere di vario tipo: l’arco senza descrizione e senza freccia indica che l’attore può eseguire una certa funzionalità, l’arco con linea continua e con freccia indica una generalizzazione (ereditarietà) e punta verso il caso generale, l’arco con la descrizione rappresenta un caso eccezionale o che si verifica di rado e punta verso il caso eccezionale, quello con la descrizione è la relazione tra due entità che indica che una determinata funzionalità implica l’esecuzione di un altra e punta verso quella che viene eseguita per implicazione. 16  Figura 2 Casi d'uso per un distributore di snack 4.2 Diagrammi di classi (class diagrams) Rappresentano la struttura di un sistema. Vengono usati durante la fase di analisi dei requisiti e il system design di un modello. È possibile definire diagrammi contenenti classi astratte e altri in cui compaiono istanze delle stesse con i relativi attributi specificati. Ogni nodo del grafo rappresenta una classe o un’istanza con un nome (nel caso di un’istanza il nome è sottolineato) e contiene i suoi attributi e i suoi comportamenti (le operazioni che essa svolge). Ogni attributo ha un tipo e ogni operazione ha una firma. 4.2.1 Classi in UML In UML una classe è composta da tre parti: 1. nome 2. attributi (lo stato) 3. metodi o operazioni (il comportamneto) Una classe può essere rappresentata anche usando soltanto la sezione nome, un nome può essere:  simple name: il solo nome della classe.  Path name: il nome della classe è preceduto dal package in cui si trova. 4.2.2 Attributi Un attributo è una proprietà statica di un oggetto, contiene un solo valore per ogni istanza. I nomi degli attributi devono essere unici all’interno di una classe. Per ciascun attributo si può specificare il tipo ed un eventuale valore iniziale. Tipicamente il nome di un attributo è composto da una parola o più parole, la prima parola ha sempre la lettera scritto in minuscolo. 4.2.2.1 Attributi derivati Attributi calcolati e non memorizzati. Si usano quando i loro valori variano frequentemente e la correttezza (precisione) del valore è importante. Il valore viene calcolato in base ai valori di altri attributi, es: età = f(dataDiNascita, oggi). 17 4.2.2.2 Attributi ridondanti Il simbolo / inserito prima del nome di un’entità indica un attributo ridondante. 4.2.3 Operazioni (Metodi/Funzioni) Un’operazione è un’azione che un oggetto esegue su un altro oggetto e che determina una reazione. Tipi di operazione:  selettore (query): accedono allo stato dell’oggetto senza alterarlo (es. “lunghezza”della classe coda).  modificatore: alterano lo stato di un oggetto (es. “appendi”della classe coda). Operazioni di base per una classe di oggetti (realizzate con modalità diverse a seconda dei linguaggi):  costruttore: crea un nuovo oggetto e/o inizializza il suo stato  distruttore: distrugge un oggetto e/o libera il suo stato Per ciascuna operazione si può specificare il solo nome o la sua signature, indicando il nome, il tipo, parametri e in caso di funzione il tipo ritornato. Stesse convenzioni dette per gli attributi sull’uso di minuscolo e maiuscolo per i nomi delle operazioni. Per organizzare meglio lunghe liste di attributi/operazioni conviene raggrupparli in categorie usando gli stereotipi. 4.2.4 Responsibility Una responsibility è un contratto o una obbligazione di una classe. Questa è definita dallo stato e comportamento della classe. Una classe può avere un qualsiasi numero di responsabilità, ma una classe ben strutturata ha una o poche responsabilità. 4.2.5 Proprietà attributi e operazioni 4.2.5.1 Visibilità È possibile specificare la visibiltà di attributi e operazioni. In UML è possibile specificare tre livelli di visibilità:  + (public): qualsiasi altra classe con visibilità alla classe data può usare l’attributo/operazione (di default se nessun simbolo è indicato). 18   # (protected): qualsiasi classe discendente della classe data può usare l’attributo/operazione.  - (private): solo la classe data può usare l’attributo/operazione. 4.2.5.2 Molteplicità La molteplicità è usata per indicare il numero di istanze di una classe, una molteplicità pari a zero indicherà una classe astratta, una molteplicità pari ad uno o una singleton class. Per default è assunta una molteplicità maggiore di uno. La molteplicità di una class è indicata con un numero intero posto nell’angolo in alto a destra del simbolo della class. La molteplicità si applica anche agli attributi, indicandola tra [..] (Es: consolePort [2..*]: Port). 4.2.5.3 Specifica attributi La sintassi completa per specificare un attributo in UML è: [visibility] name [ [multiplicity] ] [: type] [= inital-value] [{property-string}] Dove property-string può assumere uno dei seguenti valori:  changeable: nessuna limitazione per la modifica del valore dell’attributo  addOnly: per attributi con molteplicità maggiore di 1 possono essere aggiunti ulteriori valori, ma una volta creato un valore non può essere né rimosso né modificato  frozen: il valore non può essere modificato dopo la sua inizializzazione 4.2.5.3 Specifica operazioni La sintassi completa per specificare un operation in UML è: [visibility] name [(parameter-list)] [:return-type] [{property-string}] Con la lista dei parametri avente questa sintassi: [direction] name: type [=default-value] Dove direction può assumere uno dei seguenti valori:  in: parametro di input  out: parametro di output  inout: parametro di input/output Property-string può assumere i seguenti valori:  isQuery: l’esecuzione dell’operazione lascia lo stato del sistema immutato. Proprietà che riguardano la concorrenza, rilevanti solo in presenza di oggetti attivi, processi o threads  sequential: la semantica e l’integrità dell’oggetto è garantita nel caso di un solo flusso di controllo per volta verso l’oggetto  guarded: la semantica e l’integrità dell’oggetto è garantita in presenza di flussi di controllo multipli sequenzializzando le chiamate alle operazioni guarded  concurrent: la semantica e l’integrità dell’oggetto è garantita in presenza di flussi di controllo multipli, trattando la operation come atomica 4.2.6 Legami e associazioni Un legame (link) rappresenta una relazione (fisica o concettuale) tra oggetti la cui conoscenza deve essere preservata per un certo periodo di tempo (Filomena Ferrucci lavora per Facoltà di Scienze). Un’associazione descrive un gruppo di legami aventi struttura e semantica comuni (Docente lavora per Facoltà). Un’associazione deve avere un nome, il nome è solitamente un verbo. Le associazioni sono bidirezionali sebbene al nome della relazione può essere associata una direzione. I link sono istanze delle associazioni. Un link connette due oggetti (Object diagram). Un’associazione connette due classi (class diagram). 19 4.2.6.1 Molteplicità delle associazioni La molteplicità dice:  Se l’associazione è obbligatoria oppure no  Il numero minimo e massimo di oggetti che possono essere relazionati ad un altro oggetto. 4.2.7 Ruoli I ruoli forniscono una modalità per attraversare relazioni da una classe ad un’altra. I nomi di ruolo possono essere usati in alternativa ai nomi delle associazioni. I ruoli sono spesso usati per relazioni tra oggetti della stessa classe (associazioni riflessive). 4.2.7.1 Interface specifier Un’associazione può avere un interface specifier, per specificare quale parte dell’interfaccia di una classe è mostrata da questa nei confronti di un’altra classe della stessa associazione. Esempio: Una classe Persona nel ruolo di supervisor presenta solo la ‘faccia’ IManager al worker; mentre una Persona nel ruolo di worker presenta solo la ‘faccia’ IEmployee al supervisor. 4.2.8 Associazione L’arco semplice rappresenta una associazione che può essere specificata anche da un testo, inoltre è possibile indicare le molteplicità: ad esempio un’entità X può essere associata ad una o più entità Y in tal caso avremo il seguente diagramma: è nella relazione Z con Entità X 1 * Entità Y 20 4.2.8.1 Classi associative Sono utilizzate per modellare proprietà delle associazioni. Alcune proprietà potrebbero appartenere all’associazione e non alle parti coinvolte. Un attributo di una classe associativa contiene un valore per ogni legame. 4.2.9 Aggregazione È possibile rappresentare chi contiene cosa sotto forma di grafo (o albero) utilizzando la linea con il rombo terminatore come nella figura. Le sue proprietà sono: transitività, anti simmetria (se A è parte di B allora B non è parte di A) e dipendenza (un oggetto contenuto potrebbe non sopravvivere senza l’oggetto contenente). File Directory * 1 4.2.10 Composizione Una particolare aggregazione che comporta l’esistenza di un’entità padre data un’entità figlio. In particolare: Neonato Madre * 4.2.11 Generalizzazione (o ereditarietà) Indica l’ereditarietà tra entità: la classe figlio eredità attributi e operazioni del padre semplificando il modello ed eliminando la ridondanza. Tutte le proprietà (attributi e operazioni) di una super classe possono essere applicati alle sottoclassi (sono ereditati). Generalizzazione ed ereditarietà godono della proprietà transitiva. È possibile definire nuove proprietà per le sottoclassi, ed è possibile ridefinire le proprietà ereditate (overriding). Anche le relazioni di una super classe valgono per le sottoclassi. Persona Studente Impiegato 4.2.11.1 Ereditarietà multipla L’overlapping può portare all’ereditarietà multipla. Una sottoclasse ha più di una super classe ed eredita le proprietà da tutte le superclassi. Comoda nella modellizzazione ma può creare conflitti nella realizzazione. 21 4.2.12 Classi astratte Una classe astratta definisce un comportamento generico. Definisce e può implementare parzialmente il comportamento di un oggetto. Dettagli più specifici sono completati nelle sottoclassi specializzate. Queste ultime sono indicate scrivendo il nome in corsivo. 4.2.13 Root, leef elementi polimorfici Per specificare che una classe non può avere discendenti si indicherà per questa la proprietà leaf sotto il nome della classe. Per specificare che una classe non può avere antenati si indicherà per questa la proprietà root sotto il nome della classe. Un’operazione per la quale esiste la stessa signature in più classi di una gerarchia è polimorfica. 4.2.14 Gerarchia di classi UML definisce 1 stereotipo: ◦ implementation: cioè la sottoclasse eredita l’implementazione della super classe ma non rende pubblica né supporta la sua interfaccia. 4 vincoli: ◦ Complete: tutte le sottoclassi sono state specificate, nessun’altra sottoclasse è permessa. ◦ Incomplete: non tutte le sottoclassi sono state specificate, altre sottoclassi sono permesse. ◦ Disjoint: oggetti del genitore possono avere non più di un figlio come tipo. ◦ Overlapping: oggetti del genitore possono aver più di un figlio come tipo. 4.2.15 Dependency Relazione semantica in cui un cambiamento sulla classe indipendente può influenzare la semantica della classe dipendente. La freccia punta verso la classe indipendente. UML defisce 17 stereotypes (organizzati in 6 gruppi) che possono essere applicati a dependency. 22 4.2.16 Realization Una relazione tra classi in cui una specifica un contratto che l’altra garantisce di compiere. La freccia punta alla classe che definisce il contratto. È un incrocio tra dependency e generalization, usata principalmente in due circostanze: contesto delle interface e delle collaboration. 4.2.16 Interfacce (definizione) Specifica il comportamento di una classe senza darne l’implementazione. Nota: Un’interfaccia si può rappresentare anche solo con un cerchio. 4.2.17 Modelli dinamici con UML Abbiamo due modelli dinamici che possono essere rappresentati con UML:  Interaction diagram: descrive il comportamento dinamico tra gli oggetti  Statechart: descrive il comportamento dinamico di un singolo oggetto Gli iteraction diagrams si suddividono in:  Sequence diagram: comportamento dinamico di un insieme di oggetti disposti in sequenza temporale.  Collaboration diagram: Mostra la relazione tra gli oggetti. Non mostra il tempo. Invece uno statechart è: una macchina a stati che descrive la risposta di un oggetto di una data classe alla ricezione di stimoli esterni (Eventi). L’activity diagram è un tipo speciale di diagramma di diagramma di stato, in cui tutti gli stati sono stati di azione. Possiamo dire quindi che la modellazione dinamica è un insieme di statechart, cioè uno statechart per ogni classe di oggetti. 4.3 Interaction diagram Descrivono il comportamento dinamico di un gruppo di oggetti che “interagiscono” per risolvere un problema. Un’ interazione è un comportamento che comprende un insieme di messaggi scambiati tra un insieme di oggetti nell’ambito di un contesto per raggiungere uno scopo. UML propone due diversi tipi di sequence diagram:  Sequence diagram  Collaboration diagram Sequence e Collaboration diagrams esprimono informazioni simili, ma le evidenziano in modo diverso. 23 4.3.1 Iterazioni e messaggi Una interazione, tipicamente, avviene tra oggetti tra cui esiste un link (istanza di un’associazione). Un messaggio è una specificazione di una comunicazione tra oggetti che trasmette informazione con l’aspettativa che ne conseguirà una attività. La ricezione di un messaggio può essere considerata una istanza di un evento. 4.4 Diagrammi sequenziali (sequence diagrams) Descrivono le sequenze di azioni e le interazioni tra le componenti. Servono a dettagliare gli use case durante la fase di analisi dei requisiti oppure durante il system design per definire le interfacce del sottosistema e per trovare tutti gli oggetti partecipanti al sistema (“chi” fa “che cosa”). I diagrammi di sequenza possono essere utilizzati nei seguenti modi:  Per modellare le interazioni ad alto livello tra oggetti attivi all’interno di un sistema  Per modellare l’interazione tra istanze di oggetti nel contesto di una collaborazione che realizza un caso d’uso  Per modellare l’interazione tra oggetti in una collaborazione che realizza una operazione In più:  Evidenziano la sequenza temporale delle azioni  Non si vedono le associazioni tra oggetti  Le attività svolte dagli oggetti sono mostrate su linee verticali  La sequenza dei messaggi scambiati tra gli oggetti è mostrata su linee orizzontali  Possono corrispondere a uno scenario specifico o a un intero caso d’uso (aggiungendo salti e iterazioni)  Si possono annotare con vincoli temporali Figura 3 Diagramma sequenziale di un passeggero che acquista un biglietto  Sull’asse X abbiamo gli oggetti, sull’asse T (asse del tempo) abbiamo il flusso del tempo.  Un messaggio sincrono si disegna con una freccia chiusa, normalmente è etichettata con il nome del metodo invocato opzionalmente con i suoi parametri e valori di ritorno.  Il life-time (durata, vita) di un metodo è rappresentato da un rettangolino che collega la freccia di invocazione con quella di ritorno. Il ritorno è disegnato con una freccia tratteggiata ed è opzionale, se viene omessa la fine del metodo è decretata dalla fine del life-time.  I messaggi asincroni si usano per descrivere interazioni concorrenti, si rappresenta con una freccia aperta.  L’esecuzione del metodo può essere assoggettata ad una condizione: [cond]: nomeMetodo()  La parola new (create) sulla freccia rappresenta la costruzione del nuovo oggetto non presente fino a quel momento nel sistema. 24   La life-line di un oggetto è la line tratteggiata che rappresenta l’esistenza di un oggetto per un periodo di tempo.  La distruzione di un oggetto si rappresenta con una X alla fine della life-line dell’oggetto. 4.4.1 Iterazioni (ricorrenze) Rappresenta l’esecuzione ciclica di più messaggi. Si disegna raggruppando con un blocco i messaggi su cui si vuole iterare. Si può aggiungere la condizione che definisce l’iterazione sull’angolo in alto a sinistra del blocco. La condizione si rappresenta al solito tra parentesi quadre. 4.4.2 Cicli e condizioni Cicli e condizioni si indicano con un riquadro (frame) che racchiude una sotto sequenza di messaggi. Nell’angolo in alto è indicato il costrutto. Tra i costrutti possibili:  Loop (ciclo while-do o do-while): la condizione è indicata tra parentesi quadra all’inizio o alla fine;  Alt (if-then-else): la condizione si indica in cima; se ci sono anche dei rami else allora si usa una linea tratteggiata per separare la zona then dalla zona else indicando eventualmente un’altra condizione accanto alla parola else;  Opt (if-then): racchiude una sottosequenza che viene eseguita solo se la condizione indicata in cima è verificata. 25 4.4.3 Auto-chiamata Descrive un oggetto che invoca un proprio metodo. 4.4.4 Esprimere vincoli sul tempo di risposta 4.4.5 Messaggi e azioni Ad un messaggio possono corrispondere diversi tipi di azioni Call: invoca una operazione di un oggetto; un oggetto può inviare un messaggio a se stesso Return: restituisce un valore al chiamante Send: invia un segnale ad un oggetto Create: crea un oggetto Destroy: distrugge un oggetto; un oggetto può distruggere se stesso I messaggi possono essere preceduti da condizioni [x > 0] messaggio() I messaggi possono indicare iterazioni * messaggio() 4.5 Diagramma a stati (state chart) Descrivono una sequenza di stati di un oggetto in risposta a determinati eventi. Rappresentano anche le transizioni causate da un evento esterno e l’eventuale stato in cui esso viene portato. Figura 4 Diagramma a stati di un orologio Uno stato rappresenta una situazione in cui un oggetto ha un insieme di proprietà considerate stabili. Una transizione modella un ca,biamento di stato ed è denotata da: Evento [Condizione] / Azione. 26 Il significato di una transizione del tipo di quella qui mostrata è:  Se l’oggetto si trova nello stato S1, e  Se si verifica l’evento E, e  Se la condizione C è verificata  Allora viene eseguita l’azione A e l’oggetto passa nello stato S2 Per indicare uno stato inziale una freccia parte da “stato inziale” ed entra in uno stato, viceversa invece per lo stato finale. Ogni transizione connette due stati. Il diagramma corrsiponde ad un automa deterministico, in cui un evento è un input, mentre un’azione è un’output. La condizione è detta anche “guardia”, L’evento è quasi sempre presente mentre condizione e azione sono opzionali. 4.5.1 Elementi grafici dello state diagram Decomposizione OR: solo uno stato viene eseguito. Decomposizione AND: gli stati vengono eseguiti concorrentemente. Se uno stato raggiunge lo stato finale prima dell’altro, il controllo aspetta lo stato finale dell’altro. Quando avviene una transizione il flusso di controllo subisce una fork per ciascuno stato in parallelo, alla fine si ricompone in un unico flusso con un join. 27 4.5.2 Caratteristiche dello stato  Gli attributi sono opzionali, e sono:  Nome: una stringa; uno stato può essere anonimo.  Entry/ Exit actions: eseguite all’ingresso/uscita dallo stato (non sono interrompibili, hanno durata instantanea).  Transizioni interne: non causano un cambiamento di stato.  Attività dello stato (interrompibile, durata significativa).  Sottostati: strutttura innestata di stati; disgiunti (sequenzialmente attivi) o concorrenti (concorrentemente attivi). 4.5.3 Caratteristiche delle transizioni  transizione esterna (stato finale diverso dallo stato iniziale)  interna (stato finale uguale allo stato iniziale) 4.5.4 Attributi (opzionali: evento [condizione]/azione)  Evento: segnale, messaggio da altri oggetti, passaggio del tempo, cambiamento  Condizione o guardia: la transizione occorre se l’evento accade e la condizione di guardia è vera  Azione: è eseguita durante la transizione e non è interrompibile (durata istantanea)  Transizioni senza eventi (triggerless): scattano secondo le seguente condizioni: o con guardia: se la condizione di guardia diventa vera o senza guardia: se l’attività interna allo stato iniziale è completata Alcune volte vogliamo rappresentare dei processi che l’oggetto esegue senza cambiare stato. Questi processi si chiamano Attività, e si mostrano negli stati con la notazione: do/attività. 4.5.5 Stato composto Uno stato composto (macro-stato) è uno stato che ha un nome, e che contiene a sua volta un diagramma. Esiste uno stato iniziale del macro-stato. I sottostati ereditano le transazioni in uscita del macro-stato. 28 4.6 Diagrammi delle attività (activity diagrams) È un particolare diagramma a stati in cui però al posto degli stati vi sono delle funzioni. Gli archi rappresentano la motivazione di esecuzione della funzione a cui punta. Figura 5 Diagramma delle attività per l'apertura di un incidente È possibile modellare situazioni di concorrenza in cui varie funzioni vengono eseguite simultaneamente utilizzando la seguente forma di grafico: Figura 6 Diagramma delle attività con concorrenza Un Activity diagram può essere associato: ◦ a una classe ◦ All’implementazione di un’operazione ◦ Ad uno Uso Case Utili per modellare ◦ comportamenti sequenziali ◦ non determinismo ◦ concorrenza ◦ sistemi distribuiti ◦ business workflow ◦ operazioni Sono ammessi stereotipi per rappresentare le azioni. 29 4.6.1 Elementi grafici Activity: una esecuzione non atomica entro uno state machine ◦ Una activity è composta da action, elaborazioni atomiche comportanti un cambiamento di stato del sistema o il ritorno di un valore Transition: flusso di controllo tra due action successive Guard expression: espressione booleana (condition) che deve essere verificata per attivare una transition Branch: specifica percorsi alternativi in base a espressioni booleane; un branch ha una unica transition in ingresso e due o più transition in uscita Synchronization bar: usata per sincronizzare flussi concorrenti ◦ fork: per splittare un flusso su più transition verso action state concorrenti ◦ join: per unificare più transition da più action state concorrenti in una sola ▪ il numero di fork e di join dovrebbero essere bilanciati 4.6.2 Swimlanes lo swimlanes raggruppa in modo omogeneo le attività, formisce anche una descrizione ad alto livello di come è organizzato l’ambito lavorativo del sistema. Costrutto grafico rappresentante un insieme partizionato di action/activity; Identificano le responsabilità relative alle diverse operazioni ◦ Parti di un oggetto ◦ Oggetti diversi In un Business Model identificano le unità organizzative Per ogni oggetto responsabile di action/activity nel diagramma è definito un swimlane, identificato da un nome univoco nel diagramma ◦ le action/activity state sono divise in gruppi, ciascun gruppo è assegnato allo swimlane dell’oggetto responsabile per esse ◦ l’ordine con cui gli swimlane si succedono non ha alcuna importanza 30  ◦ le transition possono attraversare swimlane per raggiungere uno state in uno swimlane non adiacente a quello di start della transition 4.7 Raggruppamento (packages) Si può cercare migliorare la semplicità di un sistema raggruppando elementi del modello in packages. Ad esempio è possibile raggruppare use case o attività. Figura 7 Raggruppamento 5 Raccolta dei requisiti (requirements elicitation) L’ingegneria dei requisiti coinvolge due attività: raccolta dei requisiti e analisi dei requisiti. La raccolta dei requisiti richiede la collaborazione tra più gruppi di partecipanti di tipologie e conoscenze diversificate. Gli errori commessi durante questa fase sono difficili da correggere e vengono spesso notati nella fase di consegna. Alcuni errori possono essere: funzionalità non specificate o incorrette o interfacce poco intuitive. Utenti e sviluppatori devono collaborare per scrivere il documento di specifica dei requisiti che è scritto in linguaggio naturale per poi essere successivamente formalizzato e strutturato (in UML o altro) durante la fase di analisi per produrre il modello di analisi. Il primo documento (la specifica dei requisiti) è utile al fine di favorire la comunicazione con il cliente e gli utenti, il documento prodotto nell’analisi è usato dagli sviluppatori. 31 La raccolta dei requisiti e l’analisi dei requisiti si focalizzano sul punto di vista dell’utente e definiscono i confini del sistema da sviluppare, in particolare vengono specificate: - Funzionalità del sistema - Interazione utente-sistema - Errori che il sistema deve gestire - Vincoli e condizioni di utilizzo 5.1 Classificazione dei requisiti Le specifiche dei requisiti sono una sorta di contratto tra il cliente e gli sviluppatori e deve essere curata con attenzione in ogni suo dettaglio. Inoltre le parti del sistema che comportano un maggior rischio devono essere prototipate e provate con simulazioni per controllare la loro funzionalità e ed ottenere un riscontro dall’utente. Esistono varie tipologie di requisiti qui di seguito specificati: 5.1.1 Requisiti funzionali Descrivono le interazioni tra il sistema e l’ambiente esterno (utenti e sistemi esterni) indipendentemente dall’implementazione. Un modo per scrivere in modo corretto i requisiti funzionali è il seguente: [condition][subject][action][object][constraint] = [condizione] [soggetto] [azione] [oggetto] [vincolo] 5.1.2 Requisiti non funzionali Descrivono aspetti del sistema che non sono legati direttamente alle funzionalità del sistema. Ad esempio sono requisiti non funzionali dettagli implementativi tipo timeout e altro. Altri requisiti non funzionali sono parte dello standard FURPS e sono di qualità e di vincoli. Qualità - Usabilità (help in linea, documentazione a livello utente) - Attendibilità (robustezza, coerenza delle funzionalità richieste) - Performance (tempo di risposta, throughput, disponibilità) - Supportabilità (manutenzione, portabilità, adattabilità) Vincoli - Implementazione (uso di tool, linguaggi, piattaforma hardware) - Interfacce (vincoli imposti da sistemi esterni tra cui sistemi legacy e formato di interscambio di dati) - Operativi (vincoli di management e amministrativi) - Packaging (riguardano i tools che sono richiesti all’utente al fine del funzionamento del software) - Legali (licenza, certificazione e regolamento) 5.2 Validazione dei requisiti I requisiti devono essere continuamente validati con il cliente e l’utente, la validazione degli stessi è un aspetto molto importante perché ha lo scopo di non tralasciare nessun aspetto. I requisiti devono rispettare le seguenti caratteristiche: Completezza (devono essere presi in considerazione tutti i possibili scenari, inclusi i comportamenti eccezionali) Consistenza (non devono contraddire se stessi) 32  Non ambiguità (deve essere definito un unico sistema e non deve essere possibile interpretare la specifica in modi differenti) Correttezza (deve rappresentare il sistema di cui il cliente ha bisogno con accuratezza) Realistiche (se il sistema può essere implementato in tempi ragionevoli) Verificabili (se una volta che il sistema è stato implementato è possibile effettuare dei test) Tracciabili (se ogni requisito può essere mappato con una corrispondente funzionalità del sistema) 5.2.1 Tracciabilità Esistono diversi tipi di tracciabilità: Source tracciability: da quale fonte arrivano i requisiti scelti dagli stakeholder, chi ha proposto i requisiti e il fondamento logico per questi requisiti. Quando viene proposta una modifica, si utilizzano queste informazioni per scoprire le parti interessate in modo che possano essere consultate in merito al cambiamento. Le informazioni sulla tracciabilità dei requisiti collegano i requisiti dipendenti all'interno del documento dei requisiti. Si utilizzano queste informazioni per valutare quanti requisiti sono interessati da una possibile modifica. Le informazioni sulla tracciabilità del design collegano i requisiti al design dei moduli in cui questi requisiti sono implementati. Si usano queste informazioni per valutare l'impatto delle modifiche proposte sui requisiti, la progettazione e l'implementazione del sistema. Il test delle informazioni di tracciabilità collega i requisiti ai casi di test dove vengono testati questi requisiti. 5.2.2 Greenfield engineering, re-engineering, interface engineering Altri requisiti possono essere specificati in base alla sorgente delle informazioni. Il greenfield engineering avviene quando lo sviluppo di un’applicazione parte da zero, senza alcun sistema preesistente. Il re-engineering è un tipo di raccolta dei requisiti dove c’è un sistema preesistente che deve essere riprogettato a causa di nuove esigenze o nuove tecnologie. L’interface engineering avviene quando è necessario riprogettare un sistema per farlo lavorare in un nuovo ambiente. Un esempio possono essere i sistemi legacy che vengono lasciati inalterati nelle interfacce. 5.3 Attività della raccolta dei requisiti 1. Identificare gli attori: durante questa attività, gli sviluppatori identificano i diversi tipi di utenti che il sistema futuro supporterà. 2. Identificare gli scenari: durante questa attività, gli sviluppatori osservano gli utenti e sviluppano una serie di scenari dettagliati per le funzionalità tipiche fornite dal sistema futuro. Gli scenari sono esempi concreti del futuro sistema in uso. Gli sviluppatori utilizzano questi scenari per comunicare con l'utente e approfondire la conoscenza del dominio dell'applicazione. 3. Identificare i casi d’uso: una volta che gli sviluppatori e gli utenti concordano su una serie di scenari, gli sviluppatori traggono dagli scenari una serie di casi d'uso che rappresentano completamente il sistema futuro. 4. Raffinare i casi d’uso: durante questa attività, gli sviluppatori assicurano che la specifica dei requisiti sia completa specificando ciascun caso d'uso e descrivendo il comportamento del sistema in presenza di errori e condizioni eccezionali. 5. Identificare le relazioni tra gli attori e i casi d’uso: durante questa attività, gli sviluppatori identificano le dipendenze tra i casi d'uso definendone le funzionalità comuni. Ciò garantisce che la specifica dei requisiti sia coerente. 6. Identificare gli oggetti partecipanti (verranno ripresi nella fase di analisi) 33 7. Identificare le richieste non funzionali: durante questa attività, sviluppatori, utenti e clienti concordano su aspetti visibili all'utente, ma non direttamente correlati alla funzionalità. Questi includono vincoli sulle prestazioni del sistema, la sua documentazione, le risorse che consuma, la sua sicurezza e la sua qualità. 5.3.1 Identificare gli attori Un attore è un’entità esterna che comunica con il sistema e può essere un utente, un sistema esterno o un ambiente fisico. Ogni attore ha un nome univoco ed una breve descrizione sulle sue funzionalità (es. Teacher: una persona; Satellite GPS: fornisce le coordinate della posizione). Un modo molto semplice per identificare gli attori di un sistema e porsi le seguenti domande: - Quali gruppi di utenti sono supportati dal sistema per svolgere il proprio lavoro, quali eseguono le principali funzioni del sistema, quali eseguono le funzioni di amministrazione e mantenimento? - Con quale sistema hardware o software il sistema interagisce? 5.3.2 Identificare gli scenari Uno scenario è una descrizione informale, concreta e focalizzata di una singola caratteristica di un sistema e descrive cosa le persone fanno e sperimentano mentre provano ad usare i sistemi di elaborazione e le applicazioni. Ogni scenario deve essere caratterizzato da un nome, una lista dei partecipanti e un flusso di eventi. Esistono vari tipi di scenari: As-is-scenario: sono usati per descrivere una situazione corrente. Vengono di solito usati nella raccolta dei requisiti di tipo re-engineering.  Visionary-Scenario: utilizzato per descrivere funzionalità future del sistema.  Evalutation-Scenario: descrivono funzioni eseguite dagli utenti rispetto alle quali poi viene testato il sistema.  Training-Scenario: sono tutorial per introdurre nuovi utenti al sistema. L’identificazione degli scenari è una fase che avviene in stretta collaborazione con il cliente e l’utente. Per poter formulare gli scenari bisogna porsi e porre all’utente le seguenti domande: - Quali sono i compiti primari che l’attore vuole che svolga il sistema? - Quali dati saranno creati/memorizzati/cambiati/cancellati o aggiunti dall’utente nel sistema? - Di quali cambiamenti esterni l’attore deve informare il sistema? - Di quali eventi/cambiamenti deve essere informato l’attore? 5.3.3 Identificare i casi d’uso Un caso d’uso descrive una serie di interazioni che avvengono dopo un’inizializzazione da parte di un attore e specifica tutti i possibili scenari per una determinata funzionalità (visto in altri termini uno scenario è un’istanza di un caso d’uso). Ogni caso d’uso contiene le seguenti informazioni: - Un nome del caso d’uso che dovrebbe includere dei verbi - I nomi degli attori partecipanti che dovrebbero essere sostantivi - Le condizioni di ingresso/uscita da quel caso d’uso. - Un flusso di eventi in linguaggio naturale - Le eccezioni che possono verificarsi quando qualcosa va male descritte in modo distinto e separato - I requisiti speciali che includono i requisiti non funzionali e i vincoli Nel flusso di eventi del caso d’uso vengono distinti gli eventi iniziati dagli attori da quelli iniziati dal sistema in quanto quelli del sistema sono più a destra (con un tab) rispetto a quelli dell’attore. 34  Figura 8 Esempio di caso d'uso per un ReportEmergency 5.3.4 Raffinare i casi d’uso Vengono dettagliati gli elementi che sono manipolati dal sistema, dettagliate le interazioni a basso livello tra l’attore e il sistema, specificati i dettagli su chi può fare cosa, aggiunte eccezioni non presenti, le funzionalità comuni tra i casi d’uso vengono rese distinte. 5.3.5 Identificare le relazioni tra attori e casi d’uso Esistono vari tipi di relazioni tra attori e casi d’uso (vedi anche lezione su UML): - Comunicazione: Bisogna distinguere due tipi di relazione di comunicazione tra attori e casi d’uso. La prima detta viene usata per indicare che un attore può iniziare un caso d’uso, la seconda invece indica che l’attore (che non ha iniziato il caso d’uso) può solo comunicare (es. ottenere informazioni) con lo stesso. In questo modo è possibile specificare già in questa fase dettagli sul controllo di accesso in quando vengono indicate le procedure e i passi per accedere a determinate funzioni del sistema. - Extend: È usato per indicare un caso d’uso eccezionale in cui si viene a finire quando si sta eseguendo un altro caso d’uso. L’arco è tratteggiato con l’etichetta e con la linea rivolta verso il caso eccezionale. - Include: Usata per scomporre un caso d’uso in dei casi d’uso più semplici. La freccia dell’arco è tratteggiata, etichettata con ed è