Corso di Ingegneria del Softwareingsoft1/Lezioni2008-2009/...Corso di Ingegneria del Software Paolo...

Corso di Ingegneria del Software

Paolo Bottoni

Introduzione allo Unified Process

Alcuni lucidi sono tratti dal materiale di supporto a UML2 and the Unified Process, di Arlow e Neustadt

© Clear View Training 2010 v2.6

Obiettivi

• Discutere UP come metodo strutturato

• Presentare fasi, attività, pratiche

• Evidenziare integrazione di diversi metodi

Blocco3ARUPIngegneria del Software 2

3

Metodi strutturati

• Approcci sistematici a sviluppo progetto software

• Documentazione usa insieme modelli grafici

• Modelli possibili

– Modello oggetti

– Modello di interazione

– Modello di transizioni di stato

– Modello strutturale

– Modello flusso di dati

Ingegneria del Software Blocco3ARUP

Blocco3ARUP 4Ingegneria del Software 4

Rational Unified Process

• Derivato da lavoro su UML e processi associati

• Normalmente descritto da 3 prospettive– Prospettiva dinamica: mostra fasi in tempo

– Prospettiva statica: mostra attività processo

– Prospettiva pratiche: suggerisce buone pratiche

• Caratteristiche:– Processo guidato da casi d’uso

– Processo centrato su architettura

– Approccio focalizzato sui rischi

55

Prospettiva dinamica: Fasi RUP

• Inception (Avvio)

– Stabilire caso di business per sistema

• Elaboration

– Comprendere dominio problema e sviluppare e architettura sistema

• Construction

– Progettazione, programmazione e test funzionalità sistema

• Transition

– Stabilire sistema in ambiente di esecuzione



Decisioni e pietre miliari

77

Prospettiva statica

Flusso di lavoro Descrizione

Business modelling Processi di business modellati con casi di business.

Requirements Si identificano attori che interagiscono con sistema e si sviluppano casi d'uso per modellare requisiti di sistema.

Analysis and design Si crea e documenta modello di progetto, usando modelli architetturali, componenti, a oggetti e di sequenza.

Implementation Componenti sistema implementati e strutturati in sotto-sistemi di implementazione. Generazione automatica di codice da modello può accelerare processo.

Test Processo iterativo congiunto a implementazione. Test di sistema segue completamento implementazione.

Deployment Creazione di rilascio prodotto, distribuzione a utenti e installazione in loro ambiente di lavoro.

Configuration and change management

Flusso di lavoro di supporto per gestire cambiamenti sistema.

Project management Flusso di lavoro di supporto per gestire sviluppo sistema.

Environment Rendere disponibili strumenti software appropriati a squadra sviluppo software.


88

Distribuzione nelle fasi


99

Contenuto delle iterazioni

• Principio: separation of concerns

• In Inception e Elaboration

– Definire ambito progetto, eliminare rischi critici, creare

architettura di base

– Iterazioni producono raffinamenti successivi

• In Construction

– Iterazioni producono incrementi

– Progetto composto da mini-progetti

• Mini-progetto realizzato in singola iterazione

• Ogni iterazione prevede attività in misura diversa


10

Inception

Inception Elaboration Construction TransitionRequirements – stabilire caso di business e

ambito. Catturare requisiti fondamentali.

Analysis – stabilire la fattibilità

Design – progettare “proof of concept” o prototipi

tecnici

Implementation – costruire “proof of concept” o

prototipo tecnico

Test – generalmente non applicabilie

Fo

cu

sG

oa

ls

Stabilire fattibilità del progetto – creare “proof of concept”/prototipi tecnici

Creare caso di business

Ambito del sistema – catturare requisiti chiave

Identificare rischi critici

RA

ID

Quantità di lavoro per

le attività principali


11

Inception - milestone

• Obiettivi ciclo di vita – Condizioni di soddisfazione:

– Ambito sistema definito

– Requisiti chiave sistema catturati.

• Definiti e concordati con stakeholder

– Esiste visione architetturale, schematica

– Valutazione rischi

– Caso di business

– Confermata fattibilità

– Stakeholder d’accordo con obiettivi progetto


12

Elaboration

Inception Elaboration Construction TransitionRequirements – raffinare ambito del sistema e

requisiti

Analysis – stabilire cosa costruire

Design – creare struttura di base architetturale

stabile

Implementation – costruire la struttura di base

architetturale

Test – provare la struttura di base architetturale

Fo

cu

sG

oa

ls

Creare una struttura di base architetturale eseguibile

Raffinare valutazione dei rischi e definire attributi di qualità (tasso di difetti, etc.)

Catturare casi d’uso fino a 80% dei requisiti funzionali

Creare un piano con dettaglio sufficiente per la fase di costruzione

Formulare un’offerta che includa costi per risorse, tempo, equipaggiamento, personale

R AI

T

D


13

Elaboration - milestone

• Architettura per ciclo di vita: Condizioni di soddisfazione– Creata base di riferimento architetturale, resistente, robusta

ed eseguibile

– Valutazione rischi aggiornata

– Creato piano di progetto che permetta di formulare offerta realistica

– Caso di business verificato rispetto a piano

– Stakeholder d’accordo su continuare


14

Construction

Inception Elaboration Construction TransitionRequirements – scoprire requisiti

eventualmente mancanti

Analysis – completare il modello di analisi

Design – completare il modello di progetto

Implementation – costruire la Capacità

Operativa Iniziale

Test – provare la Capacità Operativa Iniziale

Fo

cu

sG

oa

ls

Completare identificazione, descrizione e realizzazione dei casi d’uso

Completare analisi, progetto, implementazione e prova

Mantenere l’integrità dell’architettura di sistema

Revisionare la valutazione del rischio

R A

ITD


15

Construction - milestone

• Capacità Operativa Iniziale - Condizioni di

soddisfazione:

– Prodotto pronto per beta testing in ambiente

utente


16

Correggere difetti

Preparare ambiente utente per il nuovo software e adattare il software per operare presso l’utente

Modificare software se emergono problemi non previsti

Creare manuale utente e altra documentazione

Fornire consulenza al cliente

Condurre revisione post-progetto

Transition

Inception Elaboration Construction TransitionRequirements – non applicabile

Analysis – non applicabile

Design – modificare il progetto se emergono

problemi durante beta test

Implementation – adattare il software per il sito

utente. Correggere errori scoperti

Test – eseguire beta test e prova di accettazione

presso l’utente

Fo

cu

sG

oa

ls

DI T


17

Transition – milestone

• Rilascio prodotto - Condizioni di

soddisfazione:

– Completati beta testing, test di accettazione e

correzione difetti

– Prodotto rilasciato verso comunità utenti


Take-away per fasi e attività RUP

• Fasi determinate da obiettivi, non da attività

• Attività si ripetono in diverse fasi, in diverse iterazioni

e possono essere svolte concorrentemente

• Iterazioni definite da obiettivi realizzativi, NON DAI

DOCUMENTI DA PRODURRE

• ATTIVITÀ NON SONO SEQUENZIALI

– Ma possono avere dipendenze logiche


1919

Buone pratiche RUP

• Sviluppare software iterativamente

• Gestire requisiti

– Casi d'uso e Supplementary Requirement Specification

• Usare architetture basate su componenti

• Modellare software visivamente

• Verificare qualità software

• Controllare cambiamenti software


20

Modelli e Flussi di lavoro


21

Notazione dei processi


2222

Processo guidato da casi d’uso

• Molti tipi di utenti: attori (anche non umani)

• Caso d'uso: sequenza di azioni effettuate da

sistema per produrre risultati di valore per attore

• Modello formato da attori e casi d'uso sistema


2323

Cattura dei casi d'uso

• Attività di raccolta requisiti

– Modello UC rappresenta requisiti funzionali

• Diagramma UC descrive parte modello e mostra

associazioni fra casi e attori

• Attori definiscono ambiente sistema

• Flussi di eventi descrivono comportamenti desiderati

• Requisiti non funzionali associabili a UC

– Performance, disponibilità, accuratezza


24

Flusso di lavoro di requisiti: ruoli


2525

Flusso di lavoro di requisiti: Artefatti


26

Completamento analisi requisiti

• Estensione flusso di lavoro base in UP con

elicitazione e tracciabilità requisiti

find functional requirements

Requirements Engineer find non-functional requirements

trace requirements to use cases

Architect

prioritise requirements


2727

Evoluzione del modello dei casi d'uso

• Da modello casi d'uso a modello analisi

• Da modello analisi a modello progetto

• Classificatori e realizzazioni casi d'uso

• Classificatori hanno strutture e operazioni,

descritti da statechart


2828

Modello di analisi

• Descrizione dettagliata requisiti

• Raffinamento casi d'uso:

– collaborazioni fra classificatori concettuali

• Permette creazione di architettura

• Ha carattere temporaneo (prime iterazioni)

• Per grandi sistemi mantenuto per tutto progetto


2929

Flusso di lavoro di analisi: ruoli


3030

Flusso di lavoro di analisi: artefatti


ATTENZIONE: dipendenza logica, non temporale

3131

Costruzione modello di analisi

• Procedimento per ogni UC

– Integrazione analisi nomi-verbi

• Responsabilità UC date a classi

– Classi con responsabilità in diversi UC

– Ogni classe deve soddisfare ogni ruolo di

collaborazione definito

– (Possibile utilizzo schede CRC)

• Realizzazione UC

– Collaborazione fra elementi


Analisi nomi verbi

32Ingegneria del Software Blocco3ARUP

Esempi di schede CRC


3434

Modello di progetto

• Modello gerarchico

– Esistono relazioni che attraversano gerarchia

• Realizzazioni UC tracciabili a realizzazioni in

modello di analisi

• Realizzazioni UC come stereotipi di collaborazioni

• Riferimento per implementazione


3535

Flusso di lavoro di progetto: ruoli


3636

Flusso di lavoro di progetto: artefatti


ATTENZIONE: dipendenza logica, non temporale

3737

Costruzione modello di progetto

• Classi e realizzazioni UC progettate per

sfruttare prodotti e tecnologie utilizzabili

• Raggruppamento classi di progetto in sotto-

sistemi e definizione interfacce fra sotto-sistemi


3838

Modello di dispiegamento

• Definizione organizzazione fisica sistema come

rete di nodi computazionali

• Verifica implementabilità UC per mezzo di

componenti eseguiti su nodi definiti


3939

Flusso di implementazione

• Pianificare integrazioni di sistema per ogni

iterazione (incrementale)

• Distribuire sistema, componenti eseguibili su

nodi in modello di dispiegamento

• Implementare classi e sottosistemi di progetto

– Classi file di codice sorgente

• Fare test unitari su componenti


4040

Modello di implementazione

• Classi progettate implementate come insiemi di file

componenti (codice sorgente)

• Classi compilate e collegate per produrre eseguibili

• Ordine implementazione/integrazione basato su UC

– Importanza della prioritizzazione


Ingegneria del Software 4141

Implementazione nelle fasi

• Fuoco di fase di costruzione

• Svolta anche durante elaborazione per

creare base architetturale

• Durante transizione per gestire difetti

riscontrati durante beta test

• Aspetti minimi in inception relativi a prototipi

di interfaccia

Blocco3ARUP

4242

Flusso di test

• Verifica che sistema implementi funzionalità

descritte in UC e soddisfi requisiti di sistema

• Modello di test formato da casi di test

– Collezione di ingressi, condizioni di esecuzione, risultati

– Tracciabilità a casi d'uso

• Black box: test definiti da casi d'uso

• White box: test definiti da realizzazioni


Flusso di test: ruoli

Ingegneria del Software 43Blocco3ARUP

Take-away su flussi di lavoro

• Ogni flusso porta a elaborazione di uno o più

modelli, in maniera iterativa e incrementale

• Modelli in continua evoluzione

• Sviluppo modello porta a rivedere altri modelli

• Analisi, progetto e implementazione possono

essere interfogliati per parti specifiche

• NON CORRISPONDONO A ANALISI, PROGETTO

E IMPLEMENTAZIONE WATERFALL


4545

Processo centrato sull'architettura

• Architettura software comporta decisioni su:

– Organizzazione sistema

– Elementi strutturali, interfacce, comportamento in

collaborazioni

– Composizione elementi in sottosistemi più grandi

– Stile architetturale

• struttura alto livello, meccanismi chiave

• Centrata su come, non su cosa

– Progetto architetturale e progetto funzionale


4646

Principi architetturali

• Principio: modularità

• Esempio di Ericcson AXE– Sistema di switching di telecomunicazioni

– 1970/oggi, 145 paesi, 180M linee, > 6000 scambi

• Modularità funzionale: blocchi di classi in base a funzioni

• Separazione progetto interfacce/sottosistemi di servizio

• Proiezione sottosistemi su componenti implementazione

• Basso accoppiamento fra sottosistemi: segnali


4747

Influenze sull'architettura

• Casi d'uso significativi per architettura (10-15%)

• Vincoli e facilitatori

– Software disponibile (di sistema, legacy, middleware),

standard e politiche, requisiti non funzionali, distribuzione

• Esperienza

– Architetture precedenti, pattern architetturali


4848

Sviluppo dell'architettura

• Iterativo in fase di elaborazione

– Decisione su disegno ad alto livello

– Aspetti generali dipendenti da dominio, scelta nodi,

selezione di vincoli e abilitatori

– Aspetti specifici applicazione

– Funzionalità completa solo quando architettura stabile


4949

Viste architetturali

• Per modello di progetto

– Sottosistemi principali, interfacce, classi principali,

classi attive, cicli di vita

• Per modello di dispiegamento

– Struttura fisica in termini di nodi connessi

– Assegnazione di componenti eseguibili a nodi

• Per modello di implementazione

– Distinzione responsabilità, e.g. client-server


5050

Processo iterativo e incrementale

• Sequenza di pietre miliari

• Iterazioni e incrementi per ogni fase

• Criteri essenziali

– Inception - adeguatezza (viability)

– Elaboration - realizzabilità

– Construction - operazionalità iniziale

– Transition - operazionalità finale


5151

Sviluppo a piccoli passi

• Principio: incrementalità

• Pianificazione ridotta

• Specifica, progetto e implementazione ridotti

• Integrazione, test e esecuzione ridotti

• Se soddisfatti, prossimo passo

• Elaborazione feedback fra passo e successivo


5252

Approccio focalizzato sui rischi

• Rischi determinano iterazioni e priorità

• Valutazione nuove tecnologie

• Soddisfazione requisiti

• Robustezza architettura

• Iterazioni esplorano rischi in ogni fase


5353

Rischi relativi alle tecnologie

• Distribuzione processi su nodi, sincronizzazione

• Casi d'uso possono dipendere da tecniche

computazionali non ben sviluppate


5454

Rischi relativi all'architettura

• UC selezionati non definiscono struttura sotto-

sistemi adeguata

• Framework per riuso non adeguati

• Nuove versioni software di qualità insufficiente


5555

Rischi relativi a soddisfazione utente

• Inadeguatezza estrazione requisiti

• Valutazione importanza funzioni


Corso di Ingegneria del Softwareingsoft1/Lezioni2008-2009/...Corso di Ingegneria del Software Paolo...

Documents

Transcript of Corso di Ingegneria del Softwareingsoft1/Lezioni2008-2009/...Corso di Ingegneria del Software Paolo...