Appunti Ingegneria del software PDF

Preview

Summary

Download Appunti Ingegneria del software PDF

Description

Appunti Ingegneria del software Indice RUP........................................................................................................................................................................... 3 Prospettiva statica: attività del RUP ..................................................................................................................... 3 Prospettiva dinamica: le fasi del RUP ................................................................................................................... 3 Distribuzione delle attività nelle fasi .................................................................................................................... 4 Buone pratiche RUP ............................................................................................................................................. 6 I modelli................................................................................................................................................................ 6 Processo centrato sull’architettura ...................................................................................................................... 8 Approccio guidato dai rischi ................................................................................................................................. 8 Documento di visione del sistema.......................................................................................................................... 10 Studio di fattibilit à.................................................................................................................................................. 13 Analisi del contesto ................................................................................................................................................ 14 Use-cases ...............................................................................................................................................................15 Attori ..................................................................................................................................................................15 Definire e disegnare gli use-cases ......................................................................................................................16 Relazioni tra use-cases .......................................................................................................................................16 Use Case Overview Diagrams .............................................................................................................................18 Modellare il flusso di lavoro del sistema – Diagramma di attività ..........................................................................19 Oggetti................................................................................................................................................................ 21 Segnali ................................................................................................................................................................ 21 Partizioni ............................................................................................................................................................ 22 Connettori ..........................................................................................................................................................22 Regioni di espansione.........................................................................................................................................22 Analisi nomi-verbi ..................................................................................................................................................23 Schede CRC.............................................................................................................................................................25 Classi di analisi – Entity -Control-Boundary Pattern ............................................................................................... 27 Diagramma delle classi (di progetto) ......................................................................................................................30 Visibilità ..............................................................................................................................................................30 Attributi – lo stato della classe ...........................................................................................................................31 Operazioni – il comportamento della classe ......................................................................................................32

Componenti statici di una classe ........................................................................................................................32 Relazioni tra classi ..............................................................................................................................................32 Vincoli................................................................................................................................................................. 34 Classi astratte ..................................................................................................................................................... 34 Interfacce ........................................................................................................................................................... 35 Templates (o classi parametriche o generiche) ..................................................................................................35 Diagramma dei packages .......................................................................................................................................37 Diagramma di sequenza ......................................................................................................................................... 39 Eventi, segnali e messaggi ..................................................................................................................................39 Frammenti di sequenza ......................................................................................................................................40 Esempio .............................................................................................................................................................. 43 Piano dei test .........................................................................................................................................................46 Cosa chiedersi per redigere il piano ...................................................................................................................46 Linee guida ......................................................................................................................................................... 46 Checklist ............................................................................................................................................................. 48 Tipi di test...........................................................................................................................................................49 Per approfondire ................................................................................................................................................50 Gestione dei rischi e garanzia di qualit à .................................................................................................................51 Processo di gestione dei rischi............................................................................................................................51 Principi di Software Quality Assurance ...............................................................................................................51 Gestione della configurazione del software (SCM) ............................................................................................. 52 Gestione dei rischi e della qualità....................................................................................................................... 53 Link utili .............................................................................................................................................................. 53

Schema di Giovanni Ficarra basato sugli argomenti del corso di Ingegneria del software del professor Bottoni, realizzato usando le sue dispense, i libri Software engineering e Learning UML e risorse online indicate per ogni paragrafo. Per contattarmi potete scrivere a [email protected].

RUP •

Caratteristiche: o Processo guidato dai casi d’uso o Processo centrato sull’architettura o Approccio guidato dai rischi

Prospettiva statica: attività del RUP 1. Business modelling: si modellano i processi di business con casi di business 2. Requirements: si identificano gli attori che interagiscono col sistema e si sviluppano casi d’uso per modellare i requisiti di sistema 3. Analysis and design: si crea e documenta il modello di progetto, usando modelli di architettura, componenti, oggetti e sequenza 4. Implementazione: le componenti del sistema sono implementate e strutturate in sotto-sistemi di implementazione, eventualmente usando la generazione automatica del codice dal modello 5. Test: processo iterativo congiunto all’implementazione, finita questa si esegue un test di sistema 6. Deployment: rilascio del prodotto, distribuzione agli utenti e installazione nel loro ambiente di lavoro 7. Configuration and change management: flusso di lavoro di supporto per gestire cambiamenti del sistema 8. Project management: flusso di lavoro di supporto per gestire lo sviluppo del sistema 9. Environment: si rendono disponibili gli strumenti software appropriati alla squadra di sviluppo del software

Prospettiva dinamica: le fasi del RUP 1. 2. 3. 4.

Inception: stabilire un caso di business per il sistema Elaboration: sviluppare e comprendere il dominio del problema e l’architettura del sistema Construction: progettazione, programmazione e test del sistema Transition: stabilire il sistema nell’ambiente di esecuzione

•

Nelle prime due fasi si definisce l’ambito del progetto, si eliminano i rischi critici e si crea l’architettura di base, le iterazioni producono raffinamenti Nella terza le iterazioni producono incrementi Il progetto è composto da mini-progetti, ognuno realizzato in un’iterazione Ogni iterazione prevede flussi di lavoro

• • •

Distribuzione delle attività nelle fasi

•

Inception: o Focus: ▪ Requirements: stabilire caso di business e contesto, raccogliere i requisiti principali ▪ Analysis: stabilire la fattibilità ▪ Design: progettare una prova di concetto o prototipi tecnici ▪ Implementation: costruire la prova di concetto o i prototipi tecnici ▪ Test: o Obiettivi: ▪ Stabilire la fattibilit à del progetto ▪ Creare un caso di business ▪ Definire contesto del sistema e requisiti chiave ▪ Identificare i rischi critici o Milestone: ▪ Ambito del sistema definito ▪ Requisiti chiave definiti e concordati con gli stakeholder ▪ Visione architetturale schematizzata ▪ Rischi valutati ▪ Caso di business creato ▪ Fattibilità confermata ▪ Stakeholder d’accordo con gli obiettivi del progetto o Criterio essenziale: adeguatezza

•

•

•

Elaboration: o Focus: ▪ Requirements: rifinire il contesto del sistema e i requisiti ▪ Analysis: stabilire cosa costruire ▪ Design: creare una base stabile per l’architettura ▪ Implementation: costruire la base dell’architettura ▪ Test: testare la base dell’architettura o Obiettivi: ▪ Creare una base dell’architettura eseguibile ▪ Rifinire i rischi e definire gli attributi di qualit à ▪ Catturare gli use case dell’80% dei requisiti funzionali ▪ Creare un piano abbastanza dettagliato per la fase di construction ▪ Formulare un’offerta che includa risorse, tempo, strumentazione, staff, costo o Milestone: ▪ Creata una base resistente, robusta ed eseguibile per l’architettura ▪ Aggiornata la valutazione dei rischi ▪ Creato un piano di progetto che permetta di formulare un’offerta realistica ▪ Verificato il caso di business rispetto al piano ▪ Stakeholder d’accordo su continuare o Criterio essenziale: realizzabilit à Construction: o Focus: ▪ Requirements: scoprire requisiti mancanti ▪ Analysis: finire il modello di analisi ▪ Design: finire il modello di design ▪ Implementation: costruire la Capacità Operativa Iniziale ▪ Test: testare la Capacità Operativa Iniziale o Obiettivi: ▪ Completare l’identificazione, la descrizione e la realizzazione degli use case ▪ Finire analisi, design, implementazione e test ▪ Mantenere l’integrità dell’architettura del sistema ▪ Revisionare la valutazione dei rischi o Milestone: ▪ Prodotto pronto per il beta testing nell’ambiente dell’utente o Criterio essenziale: operazionalit à iniziale Transition: o Focus: ▪ Requirements: ▪ Analysis: ▪ Design: modificare il design se nel beta testing emergono problemi ▪ Implementation: adattare il software all’ambiente dell’utente e correggere bug scoperti nel beta testing ▪ Test: eseguire il beta testing e il test di accettazione nell’ambiente dell’utente

o

o

o

Obiettivi: ▪ Correggere i difetti ▪ Preparare l’ambiente dell’utente per il nuovo software ed adattare il software per operare in quell’ambiente ▪ Modificare il software se emergono problemi non previsti ▪ Creare manuali utente e altra documentazione ▪ Fornire consulenza al cliente ▪ Condurre revisioni post progetto Milestone: ▪ Completati beta testing, test di accettazione e correzione dei difetti ▪ Prodotto rilasciato agli utenti Criterio essenziale: operazionalit à finale

Buone pratiche RUP • • • • • •

Sviluppare software iterativamente Gestire requisiti tramite use case e Supplementary Requirement Specification Usare architetture basate su componenti Modellare il software visivamente Verificare la qualità del software Controllare i cambiamenti del software

I modelli

•

•

•

•

•

Modello degli use case: o Formato da attori e casi d’uso: ▪ Gli attori rappresentano i tipi di utenti, definiscono l’ambiente del sistema ▪ I casi d’uso rappresentano sequenze di azioni effettuate dal sistema per produrre risultati di valore per un attore, descrivono i comportamenti desiderati o Rappresenta i requisiti funzionali o Evoluzione: ▪ Dal modello dei casi d’uso si passa al modello di analisi, e da lì a quello di progetto ▪ Classificatori (dotati di strutture e operazioni, descritti da statechart) e realizzazioni dei casi d’uso Modello di analisi: o Descrizione dettagliata dei requisiti o Raffinamento dei casi d’uso con collaborazioni tra classificatori concettuali o Permette di creare l’architettura o Ha carattere temporaneo (vale per le prime iterazioni), viene mantenuto solo per grandi sistemi o Costruzione (eventualmente usando schede CRC): ▪ Ogni use case è integrato tramite analisi nomi-verbi ▪ Le responsabilità egli use case sono date alle classi (le classi hanno responsabilit à in diversi casi d’uso e devono soddisfare ogni ruolo di collaborazione definito) ▪ Ogni use case è realizzato grazie alla collaborazione tra più elementi Modello di design: o Modello gerarchico: esistono relazioni che attraversano la gerarchia o Si possono tracciare le realizzazioni degli use case nelle realizzazioni del modello di analisi o Le realizzazioni degli use case diventano stereotipi di collaborazioni o Riferimento per l’implementazione o Costruzione: ▪ Classi e realizzazioni use case progettate per sfruttare prodotti e tecnologie utilizzabili ▪ Raggruppamento classi di progetto in sottosistemi e definizione interfacce tra sottosistemi Modello di deployment: o Definizione dell’organizzazione fisica del Sistema come rete di nodi computazionali o Verifica dell’implementabilità degli use case tramite componenti eseguiti sui nodi definiti Modello di implementazione: o Costruzione: ▪ Pianificare le integrazioni del sistema per ogni iterazione ▪ Distribuire sistema e componenti eseguibili sui nodi del modello di deployment ▪ Implementare le classi e i sottosistemi di progetto, passando dalle classi al codice ▪ Fare test unitari sui componenti o Le classi progettate sono implementate come insiemi di file component o Le classi vengono compilate e collegate per produrre eseguibili o Si procede in base alle priorità stabilite dagli use case

•

Modello di test: o Costruzione: ▪ Verifica che il Sistema implementi le funzionalit à descritte negli use case e soddisfi I requisiti di sistema ▪ Il modello di test è formato dai casi di test (ingressi, condizioni di esecuzione, risultati) tracciabili ai casi d’uso ▪ Black box: test definiti dai casi d’uso ▪ White box: test definiti dalle realizzazioni

Processo centrato sull’architettura • • •

•

•

•

L’architettura comporta decisioni su organizzazione del sistema, elementi strutturali, interfacce, comportamento nelle collaborazioni, composizione di elementi in sottosistemi, stile architetturale È centrata sul come e non sul cosa: progetto architetturale e progetto funzionale Principi: o Modularità funzionale: blocchi di classi in base alle funzioni o Separare il progetto delle interfacce dai sottosistemi di servizio o Proiezione dei sottosistemi sui componenti di implementazione o Basso accoppiamento tra sottosistemi: segnali Influenze sull’architettura: o Casi d’uso significativi o Vincoli e facilitatori (software, standard e politiche, requisiti non funzionali, distribuzione) o Esperienza (architetture precedenti, pattern) Lo sviluppo dell’architettura è iterativo e avviene in fase di elaborazione: o Decisione sul disegno ad alto livello o Parti generali per il dominio, scelta dei nodi, selezione di vincoli e abilitatori o Aspetti specifici dell’applicazione o Funzionalità completa solo quando l’architettura sarà stabile Viste architetturali: o Per modello di progetto: sottosistemi principali, interfacce, classi principali, classi attive, cicli di vita o Per modello di deployment: struttura fisica in termini di nodi connessi, assegnazione di componenti eseguibili ai nodi o Per modello di implementazione distinzione responsabilit à

Approccio guidato dai rischi • • •

•

I rischi determinano iterazioni e priorit à Le iterazioni esplorano i rischi in ogni fase Rischi nella valutazione nuove tecnologie: o Distribuzione dei processi sui nodi e sincronizzazione o I casi d’uso possono dipendere da tecniche computazionali non ben sviluppate Rischi nella soddisfazione dei requisiti: o Inadeguatezza dell’estrazione dei requisiti o Valutazione dell’importanza delle funzioni

•

Rischi nella robustezza dell’architettura: o Casi d’uso selezionati non definiscono adeguatamente la struttura dei sottosistemi o I framework per il riuso non sono adeguati o Le nuove versioni del software sono di qualit à insufficiente

Documento di visione del sistema • • • • • • • •

•

Realizzato dal manager di prodotto, guiderà l’intero progetto Definisce obiettivi, funzionalità e vincoli del nuovo prodotto dal punto di vista degli stakeholders Espone una visione chiara del problema, il suo ambito e le soluzioni proposte Costituisce la base per il contratto e per la definizione dei requisiti dettagliati, rispetto ai quali è più breve e generico Viene realizzato all’inizio della fase di Inception del processo RUP, si prevede che possa essere modificato man mano che i requisiti evolvono Serve come base per gli use case È aggiornato e mantenuto come artefatto separato lungo il progetto Comprende: o Introduzione o Specifica delle features/requisiti o Ambito e limitazioni o Pianificazione o Definizione del team di progetto o Descrizione degli stakeholders o Posizionamento nel mercato È strutturato in: o Introduzione: ▪ Panoramica del documento, ne definisce scopo, a...