Sei sulla pagina 1di 31

Politecnico Politecnico

di Milano di Milano
Il Il ciclo ciclo di di vita del software vita del software
Una Una v visione isione ad alto ad alto livello livello
Fasi principali dello sviluppo di software
Spazio del problema
Studio del problema (analisi dei requisiti)
Creazione di un documento di descrizione del problema
Spazio della soluzione
Definizione e descrizione della struttura della soluzione
(progettazione)
Implementazione della soluzione
Deployment della soluzione
Evoluzione della soluzione
Attivit trasversali
Project management
Convalida e verifica (testing)
Configuration management
Ciclo di vita del software: schema secondo cui sono organizzate
le fasi di sviluppo
Spazio Spazio del del problema problema
Un prodotto software sviluppato per risolvere un
problema
Quindi, per trovare una soluzione necessario
studiare e capire il problema
Talvolta, questa fase chiamata analisi
intendendo dire analisi del problema o anche
analisi dei requisiti e analisi object-oriented
Ci riferiremo a questa attivit con il termine
problem definition
Problem Problem definition definition (1/2) (1/2)
Scopi dellattivit
Raccolta, classificazione e gestione dei requisiti
utente
Definizione (specifica) delle interfacce (utente e
informatiche) con altri sistemi
Controllo dei cambiamenti nei requisiti, valutazione
dellimpatto dei cambiamenti
Ruolo degli strumenti informatici
Repository dei requisiti
Registrazione delle relazioni/dipendenze fra requisiti,
analisi di consistenza
Change impact analysis
Problem Problem definition definition (2/2) (2/2)
Relazioni con altre attivit/fasi
Project management: informazioni per stima dei costi,
pianificazione,
Configuration management: gestione delle versioni dei
requisiti, dipendenze con altri semilavorati
Testing: i requisiti forniscono un input per costruire
alcuni casi di test
Spazio Spazio della della soluzione soluzione
Senza dubbio, la comprensione di un problema non
sufficiente: dobbiamo ideare una soluzione per tale problema
Per creare una soluzione, gli ingegneri e gli architetti sono
soliti definire prima la sua struttura (o architettura)
Larchitettura deve poi essere raffinata nei componenti che si
dovranno implementare
Due termini comuni usati in questo contesto sono
Progetto architetturale: lattivit in cui un ingegnere del software
crea larchitettura di un sistema software
Progetto di dettaglio: lattivit in cui unarchitettura
progressivamente decomposta in componenti pi piccoli e
specializzati (mattoni architetturali), fino ad arrivare a
componenti direttamente implementabili
Questa fase nel suo complesso verr denominata con il termine
program design
S Software oftware Design e System Design Design e System Design
Spesso una soluzione non si basa soltanto sul
software
una combinazione di hardware, software e di un
certo numero di dispositivi e di prodotti: un sistema
System design: progettare una configurazione di
sistema, costituita da elementi hardware e software
che operano congiuntamente per mettere in esercizio
la soluzione
Implementazione Implementazione della della soluzione soluzione
Implementazione
Codifica: sviluppo del codice relativo ai mattoni
architetturali (moduli) che costituiscono la soluzione
Documentazione: commenti nel codice, manuali,
Test in piccolo: verifica delle funzionalit e della
qualit del codice sviluppato
Deployment Deployment della della soluzione soluzione
Messa in esercizio della soluzione
Attivit attraverso la quale un prodotto software viene
reso disponibile agli utilizzatori
Pu essere unattivit critica in contesti particolari
(per esempio, il deployment di una nuova versione del
software di controllo di una centrale telefonica)
Evoluzione Evoluzione della della soluzione soluzione
Come afferma Brooks, il software cambia in
continuazione
Soltanto i prodotti software non utilizzati non
cambiano
Di conseguenza, necessario migliorare, modificare
e cambiare in continuazione il software
Software evolution
Tradizionalmente, questa attivit chiamata
software maintenance
Il termine per fuorviante perch maintenance
di solito fa riferimento alla correzione dei difetti o
alla prevenzione dei malfunzionamenti
Far evolvere il software pi di questo
Uno Uno schema schema riassuntivo riassuntivo
Studio del problema
Progettazione della soluzione
Implementazione della soluzione
Deployment della soluzione
Evoluzione della soluzione
Problem
Definition
Problem
Definition
Implementation Implementation
Software
Deployment
Software
Deployment
Software
Evolution
Software
Evolution
Program Design Program Design
Architectural
Design
Architectural
Design
Detailed
Design
Detailed
Design
Problem
Definition
Document
Problem
Definition
Document
Software Software
Artfacts Artfacts
Deployed
Software
Deployed
Software

Problem Design
Document
Problem Design
Document
Software
Arch.
Software
Arch.
Detailed
Design
Detailed
Design
_ __ __ _
___ ___
__ ___ _
_ ___ _
__ ___
____ __
_ __ __ _
___ ___
__ ___ _
_ ___ _
__ ___
____ __ R
e
q
u
i
r
e
m
e
n
t
s
!!! !!!
!!!
Attivit trasversali Attivit trasversali
Project management
Stima di effort e costi
Pianificazione
Allocazione delle risorse
Controllo di avanzamento
...
Testing
Verifica e validazione del software (in senso lato)
Configuration management
Gestione delle versioni e delle configurazioni dei
prodotti e dei semilavorati
Project Project management (1/2) management (1/2)
Scopi dellattivit
Pianificazione del progetto
Definizione di obiettivi e strategie del progetto
Previsione delleffort necessario a conseguire gli
obiettivi pianificati
Previsione dei costi
Gestione del gruppo di lavoro
Definizione della struttura organizzativa del gruppo di
lavoro
Controllo
Verifica di quanto stabilito durante la fase di
pianificazione
Project Project management (2/2) management (2/2)
Ruolo degli strumenti informatici
Supporto alle attivit di pianificazione e monitoraggio
Relazioni con altre fasi/attivit
Praticamente con tutte le altre fasi del processo
Esempio: Esempio: tool tool di PM di PM Testing Testing
Scopi dellattivit
Convalida e verifica rispetto a requisiti e specifiche
Individuazione della presenza di difetti
Ruolo degli strumenti informatici
Generazione e gestione dei casi di test
Esecuzione (semi)automatica dei test, test di regressione
Relazioni con altre fasi/attivit
Gestione dei requisiti e specifica dei requisiti
Configuration Configuration management (1/2) management (1/2)
Scopi dellattivit
Gestione delle versioni e delle configurazioni dei
semilavorati (sorgenti, documenti, casi di test, pagine
web, ) durante tutto il processo di sviluppo
Ruolo degli strumenti informatici
Gestione delle versioni
Repository versionato, controllo accessi, coordinamento
Supporto a build, release, distribuzione del software
Gestione delle segnalazioni di malfunzionamenti e
richieste di modifica
Workflow o diagramma degli stati: processo per la
risoluzione dei malfunzionamenti
Configuration Configuration management (2/2) management (2/2)
Relazioni con altre attivit/fasi
Praticamente con tutte le altre fasi del processo
Fonte di informazioni sul processo e sul prodotto
Metriche di prodotto (dimensioni, numero moduli, trend)
Metriche di processo (durata delle attivit)
Metriche di qualit (statistiche su malfunzionamenti)
Organizzazione Organizzazione delle delle fasi fasi: : il il
processo processo di di sviluppo sviluppo software software
Le fasi di sviluppo del software discusse finora possono essere
portate a termine seguendo schemi diversi (cicli di vita)
necessario specificare inoltre:
come organizzare e suddividere in passi operativi le attivit
di sviluppo del software
gli strumenti e le tecnologie da usare
le persone coinvolte e i relativi ruoli nelleseguire questi
passi
Software process:
organizzazione, procedure, strumenti e prassi utilizzati per
sviluppare uno specifico prodotto software
un ciclo di vita definisce lo schema secondo cui il processo
software organizzato
Riferimenti Riferimenti
IEEE Std 610.12-1990, Standard Glossary of Software Engineering
Terminology, The Institute of Electrical and Electronics Engineers
Inc., 1990
F.P. Brooks, The Mythical Man-Month - Anniversary Edition, Addison-
Wesley, 1995
M. Jackson, Software Requirements & Specifications, Addison-
Wesley, 1995
B.L. Kovitz, Practical Software Requirements, Manning, 1999
R.S. Pressman, D. Ince, Software Engineering: A Practitioners
Approach (European Adaptation) 5th Edition, McGraw-Hill, 2000
C. Ghezzi, M. Jazayeri, D. Mandrioli, Fundamentals of Software
Engineering, Prentice-Hall, 1991
C. Ghezzi, A. Fuggetta, S. Morasca, A. Morzenti, M. Pezz, Ingegneria
del Software, Mondadori Informatica Milano, 1991
A. Fuggetta et al., WebBook di Ingegneria del Software, 2001
Politecnico Politecnico
di Milano di Milano
Definizione Definizione del del problema problema
Concentrarsi sul problema Concentrarsi sul problema
Per poter sviluppare una soluzione software
necessario dapprima studiare e comprendere
correttamente il problema
Spesso risulta difficile distinguere tra problema e
soluzione
individuare dove risiedono il problema e la soluzione.
Requisiti Requisiti
Come possiamo definire/descrivere un problema in
modo da consentire la realizzazione di un sistema
informatico per la sua soluzione?
Occorre fornire ai progettisti e sviluppatori tutte le
informazioni necessarie sul comportamento
atteso/desiderato del sistema
Queste informazioni rappresentano i requisiti requisiti del
software da realizzare.
Per requisito requisito si intende qualsiasi criterio, condizione o
vincolo che un semilavorato deve soddisfare per essere
accettato.
Come descrivo i requisiti? Posso utilizzare un
linguaggio di uso comune (per esempio, litaliano)
oppure un linguaggio specializzato (per esempio UML)
Requirement engineering Requirement engineering
Definire dei requisiti significa rispondere ad un insieme di
domande che dipendono dalla natura dellartifatto da
realizzare.
Esempio: se dobbiamo realizzare un ponte, alcune domande
rilevanti possono essere:
Quale traffico, espresso in numero di auto allora, deve essere
sopportato dal ponte?
Auto o soltanto pedoni?
Deve consentire il passaggio di camion? Qual il peso massimo
consentito?
Requirement Engineering
E larte di definire i requisiti.
Pu essere visto come una attivit progettuale, nel senso
che lingegnere deve decidere/definire le tipologie di
effetti che il software dovr esercitare nel dominio
applicativo.
Problemi Software Problemi Software
Possono essere ricondotti alla seguente
formulazione:
Configurare la macchina M per produrre effetti R nel
dominio applicativo D
... dove
M rappresenta la macchina e la sua configurazione
(cio il software specifico eseguito).
R sono i requisiti.
D la parte del mondo reale in cui M deve essere
utilizzata per realizzare gli effetti descritti da R.
Il dominio applicativo Il dominio applicativo
(o dominio del problema) (o dominio del problema)
E la parte del mondo reale nella quale si ipotizza
che il software produrr i suoi effetti.
Per comprendere lo spazio del problema
necessaria una conoscenza approfondita del dominio conoscenza approfondita del dominio
applicativo applicativo:
Esempio: per sviluppare software di avionica
necessario, come minimo, conoscere i principi di
funzionamento di un aeroplano
Lingegnere del software deve quindi essere in grado
di interagire con esperti di dominio esperti di dominio per acquisire
tale conoscenza.
Esempio Esempio - - SW di Controllo per un SW di Controllo per un
Aeroplano Aeroplano
Dominio applicativo:
Insieme di fenomeni riguardanti il mondo dellavionica
(in particolare quelli correlati allo specifico problema da
affrontare)
Descrizione aderente alla realt di fatti e relazioni fra fatti
(propriet)
La macchina: fatti e propriet del SW di controllo
Cattura aspetti della soluzione
Esistono fenomeni condivisi fra i due domini
La fase di analisi dei requisiti si disinteressa della parte del
dominio della macchina non condivisa con il dominio
applicativo
Requisiti: esprimono propriet desiderate per la soluzione
Es. Il sistema di controllo deve azionare linversione dei
motori solo dopo che l'aeroplano in atterraggio si posato
Specifiche: indicano limpatto dei requisiti sulla macchina
Esempio Esempio - - Domini e Relazioni fra i Domini e Relazioni fra i
Domini Domini
Phenomena and properties of the
application domain
Phenomena and properties
of the "machine" to be built
Shared phenomena
I fenomeni condivisi sono parte sia del dominio applicativo, sia
della macchina che deve essere costruita.
Esempio Esempio - - Domini e Relazioni fra i Domini e Relazioni fra i
Domini (2) Domini (2)
Esempio Esempio - - Requisiti e Specifica Requisiti e Specifica
Requisito: si vuole che linversione dei motori sia
attivata se e solo se laereo sta correndo sulla pista
REVERSE_ENABLED if and only if MOVING_ON_RUNWAY
una descrizione esplicita del problema da risolvere
Da questo requisito e dalla conoscenza del domino
applicativo si deriva la specifica vera e propria:
REVERSE_ENABLED if and only if WHEEL_PULSES_ON
E la specifica dellinterfaccia della macchina, in
quanto espressa solo in termini di fenomeni condivisi
(di interfaccia)
Osservazione Osservazione
La precedente specifica sbagliata poich non
considera la possibilit di slittamento delle ruote
sulla pista bagnata: quando ci accade le ruote non
girano e di conseguenza il meccanismo di inversione
dei motori non viene attivato
Il malfunzionamento non dovuto ad una specifica
errata o a un bug nel codice, ma
fondamentalmente ad una errata comprensione e
descrizione del dominio applicativo!!
Two worlds and three design Two worlds and three design
Kovitz, 1999
Dominio applicativo e dominio della Dominio applicativo e dominio della
macchina macchina
Aspetto critico: qual la linea di demarcazione fra
dominio applicativo e dominio della macchina?
In altri termini: cosa deve essere considerato parte del
problema e cosa deve essere considerato parte della
soluzione?
Non si pu dare una risposta generale!
Esempio Esempio
Sviluppo di un sistema informativo.
Dominio: lazienda che deve essere informatizzata.
Soluzione (macchina): il sistema informativo da
realizzare.
Sviluppo di un tool statistico per analizzare lutilizzo
del sistema informativo:
Dominio: lazienda ed il suo sistema informativo ed il suo sistema informativo.
Macchina: il software statistico da sviluppare.
Cosa non sono i requisiti di un Cosa non sono i requisiti di un
sistema software (1) sistema software (1)
Non sono il punto di partenza di uno sviluppo top-
down
Un programma non un raffinamento di un
documento di descrizione dei requisiti.
Un programma potrebbe per avere una struttura
simile a quella del dominio applicativo (come
suggerito da molti metodi OO).
Questa per soltanto una delle possibilit. In generale,
la struttura della soluzione pu essere definita in
accordo a diverse architetture architetture, intrinsecamente diverse
tra loro e con struttura, in generale, non esattamente
corrispondente a quella dello spazio del problema.
Cosa non sono i requisiti di un Cosa non sono i requisiti di un
sistema software(2) sistema software(2)
Non sono delle bozze del programma
Un documento di descrizione dei requisiti non uno
schema preliminare dellapplicazione che verr
realizzata.
E una descrizione molto dettagliata molto dettagliata dello spazio del
problema.
Convalida Convalida dei dei requisiti requisiti
Gli errori compiuti nelle fasi iniziali dello sviluppo
(specialmente nellanalisi e specifica dei requisiti) sono i pi
gravi e dannosi
Obiettivo (generale) scoprire gli errori immediatamente dopo
che sono stati commessi
Modi per raggiungerlo
costruire prototipi; attivit complessa e molto costosa
documentare e revisionare subito tutte le decisioni
esaminare insieme al cliente tipici esempi duso, gli
SCENARI
iniziare con quelli di funzionamento usuale e in cui lutente
non fa errori
considerare anche casi di errori del cliente o del sistema
stesso
decidere quanti errori si vogliono prevedere, riconoscere e
gestire
Struttura di un documento di Struttura di un documento di
descrizione dei requisiti descrizione dei requisiti
Costituito da 3 parti:
Descrizione del dominio applicativo
Descrizione dei requisiti
effetti che il software deve esercitare sul dominio
applicativo.
Specifica (design dellinterfaccia) della macchina da
realizzare.
Descrizioni e specifiche possono essere scritte in
qualsiasi linguaggio (informale, semi-formale,
formale)
Politecnico Politecnico
di Milano di Milano
UML UML
UML: Unified Modeling Language
Notazione object-oriented utilizzabile durante le fasi di analisi
e design di un sistema.
E' diventato uno standard di fatto per object-oriented
modelling
Evoluzione e unificazione di tre notazioni: Booch
(dell'omonimo autore), OMT (di Rumbaugh) e OOSE (di
Jacobson).
UML indipendente da qualsiasi linguaggio di programmazione
UML utilizzabile in domini applicativi diversi e per progetti di
diverse dimensioni
UML estendibile per modellare meglio le diverse realt
Diagrammi UML Diagrammi UML
Viste statiche
Use Case Diagram
Class Diagram
Component Diagram
Deployment Diagram
Viste Dinamiche
State Diagram
Activity Diagram
Collaboration Diagram
Interaction Diagram
Sequence Diagram
Politecnico Politecnico
di Milano di Milano
Use Case Diagram Use Case Diagram
Definizione dei Requisiti Definizione dei Requisiti
Il primo passo di qualsiasi processo di sviluppo
la definizione dei requisiti
Definizione del Business Model
Solitamente informale e in linguaggio naturale
Jacobson (OOSE) propone una notazione particolare
che confluita in UML
Use Case Diagram
Use Cases Use Cases
Definiscono il comportamento del sistema
Le funzionalit (processi) principali
Come il sistema agisce e reagisce
Descrivono
Il sistema
Lambiente
Le relazioni fra sistema e ambiente
Diversi livelli di dettaglio
Scomposizione gerarchica simili ai DFD
Elementi Fondamentali Elementi Fondamentali
Actor: qualcuno (utente) o qualcosa
(sistemi esterni - hardware) che:
Scambia informazioni con il sistema
Fornisce input o riceve output dal sistema
Use Case: ununit funzionale parte del
sistema
Relazioni Fondamentali Relazioni Fondamentali
interazione indica relazioni tra attori
e casi
uses indica luso di una certa
funzionalit (utile quando
funzionalit simili sono presenti in
diversi contesti)
extends definisce una funzionalit
per estensione di una funzionalit gi
esistente
<uses>
<extends>
Esempio: registrazione Corsi Esempio: registrazione Corsi
Allinizio dellanno accademico, lufficio
amministrativo delluniversit fornisce agli studenti
la lista di corsi disponibili, attraverso un sistema di
registrazione.
Il sistema deve consentire agli studenti di
selezionare quattro corsi fra quelli disponibili. In
aggiunta ogni studente deve indicare due
alternative.
Nessun corso pu avere pi di 10 studenti. Corsi con
meno di 3 studenti vengono cancellati
automaticamente.
Registrazione Corsi (cont.) Registrazione Corsi (cont.)
I professori devono poter accedere al sistema per
indicare i corsi in cui vorrebbero insegnare e per
vedere gli studenti iscritti ai loro corsi.
Il processo di registrazione dura 3 giorni.
Il primo giorno riservato agli studenti del primo
anno.
Il secondo giorno riservato agli altri studenti.
Durante il terzo giorno si risolvono eventuali conflitti.
Finito il processo di registrazione, le informazioni
relative ad un studente sono inviate allufficio
contabile per determinare le tasse da pagare.
Cambiamento Organizzazione Corso
Richiesta Iscritti
Professore
Selezione Corso
Gestione Professori
Gestione Studenti
Archivio
Gestione Corsi
Richiesta Catalogo Corsi
Cambiamento Piano studi
Studente
Registrazione Corsi
Ufficio Contabile
Registrazione Corsi Registrazione Corsi Actor Actor
Gli attori identificano i ruoli
Pi utenti con lo stesso ruolo
Pi ruoli per il medesimo utente
Utili per configurare il sistema in funzione dei ruoli
che accedono alle funzioni di alto livello
Definizione dei permessi concessi agli utenti in base al
ruolo
Utili per tracciare i requisiti del sistema
Chi usa cosa
Risoluzione dei conflitti fra ruoli
Definizione esigenze di sicurezza e riservatezza
Use Case Use Case
Gli use case possono essere ricavati dalle interviste
con gli utenti. Si identificano
Gli obiettivi: ci che il sistema dovrebbe fare secondo
gli utenti
Le interazioni: cosa vorrebbero (potrebbero) fare i
diversi utenti
Gli use case di alto livello sono volutamente
generici
non introdurre prematuramente scelte progettuali
Use Case (cont.) Use Case (cont.)
Come individuare gli use case
Analisi degli eventi esterni
Gli eventi rilevanti devono suscitare reazioni del
sistema, cio use case
Analisi degli attori
Un attore pu essere il beneficiario di uno use case
Un attore pu essere coinvolto in uno use case
Un attore pu essere il controllore di uno use case
Un attore pu semplicemente essere informato del
completamento di uno use case
Use Case (cont.) Use Case (cont.)
Il processo di definizione degli use case iterativo
Si inizia identificando i comportamenti pi semplici
Si descrivono i comportamenti alternativi e pi
complessi
Quando smettere?
Un buon livello di dettaglio facilit tutte le attivit
successive
Troppi dettagli
Complicherebbero inutilmente la descrizione
Introdurrebbero prematuramente scelte progettuali
Precluderebbero la visione dinsieme
Extends Extends
Extends indica che uno use case simile a un altro
ma pi specifico.
Si descrive lo use case pi specifico per differenze
rispetto a quello pi generale
Esempi
Pagamento prodotto e pagamento con carta di credito
Calcola prezzo prodotto e calcola prezzo scontato
Extends (cont.) Extends (cont.)
Partire dal caso pi generale (relativamente al
problema)
Scovare le varianti pi specifiche in base a
Differenze rispetto al caso base
Trattamenti specifici
Lavoro aggiuntivo
Esplicitare le specializzazioni significative rispetto al
caso normale
Miglior comprensibilit
Maggior riuso
Uses Uses
Uses fattorizza attivit ricorrenti e condivise
Analogie con
Chiamata a sottoprocedura in un linguaggio di
programmazione
Esempi
La richiesta del numero di CC per ogni operazione bancaria
La consultazione del catalogo di una biblioteca
Le funzioni matematiche pi complesse (sin, cos, log, ecc.)
cliente
impiegato
Gestione credito
Rich. ordine Ordine via Internet
extends
Dati cliente
uses
Disp. prodotto
uses
Mod. pagamento
uses
uses
Un esempio Un esempio Riassumendo Riassumendo
Extends (al contrario, Generalization)
Descrive una specializzazione rispetto al caso normale
Facilita la fattorizzazione (riuso) di comportamenti
simili
Uses (al contrario, Include)
Identifica un componente (parte) di un caso pi
complesso
Massimizza ed evidenzia i componenti riutilizzabili
Documentazione Documentazione
Per ogni use case:
Titolo: Computo tasse
Autori: Pluto e Topolino
Descrizione: Quando le iscrizioni di uno studente
sono state accettate si inviano le informazioni
allufficio contabile
Attori: Ufficio contabile
Pre-condizioni: Studente registrato
Post-condizioni: Non identificate
Scenari:.....
Scenari Scenari
Uno scenario unistanza di uno use case
una esecuzione particolare dello use case
Rappresenta il comportamento (le azioni e gli eventi) del
sistema nel caso particolare considerato
Gli scenari definiscono requisiti di pi basso livello
rispetto agli use case
Gli scenari sono solitamente definiti in linguaggio
naturale
UML propone una notazione particolare
Interaction Diagram
Scenari Scenari
Ogni use case dovrebbe essere corredato da un
insieme di scenari
Scenari principali (pi possibile)
Tutto funziona correttamente
Scenari secondari (pochi e significativi)
Eccezioni (eventuali problemi o malfunzionamenti)
Quanti scenari si devono definire?
Servono tanti scenari quanti sono quelli necessari per
capire il corretto funzionamento del sistema e le
eccezioni che si ritengono significative in durante
lanalisi
Oltre lAnalisi dei Requisiti Oltre lAnalisi dei Requisiti
Convalida del sistema
Gli use case possono essere utilizzati per ricavare i
dati di test con cui convalidare il sistema
Ogni use case rappresenta una funzionalit che
andrebbe verificata
Gestione del progetto
Gli use case propongono una nuova unit di misura
Gli use case potrebbero essere utili per
Organizzare il progetto
Stimare la complessit
Esercizio Esercizio
Si definisca un semplice Use Case Diagram per
modellare il sistema informativo di una societ di
autonoleggio.
Il sistema deve gestire
le prenotazioni (sia telefoniche, che via Internet),
la richiesta diretta di unautovettura,
la fatturazione,
linvio di solleciti in caso di ritardo nella riconsegna,
e il parco macchine.
Riassumendo Riassumendo
Gli use case
rappresentano i requisiti del sistema
forniscono una base per la pianificazione ed il
controllo del progetto
Il processo di definizione un processo iterativo
Dal generale al grado di dettaglio richiesto
Listanziazione degli use case avviene definendo gli
scenari corrispondenti ad ogni use case
Interaction Diagram Interaction Diagram
Interaction Diagram Interaction Diagram
Descrivono il comportamento dinamico di un gruppo
di oggetti che interagiscono per risolvere un
problema
Sono utilizzati per formalizzare gli scenari in
termini
Entit (oggetti)
Messaggi scambiati (metodi)
UML propone due diversi tipi di Interaction Diagram
Sequence Diagram
Collaboration Diagram
Sequence Diagram Sequence Diagram
Evidenziano la sequenza temporale delle azioni
Non si vedono le associazioni tra oggetti
Usabili in due forme diverse
La forma generica: tutte le sequenze (esecuzioni)
possibili
La forma distanza: una sequenza particolare
(consistente con quella generica)
Paperino Selettore Informatica
scegli informatica
disponibile?
aggiungi Paperino
conferma registrazione
Sequence Diagram Sequence Diagram
Sequence Diagram Sequence Diagram
(Sistemi in Tempo Reale) (Sistemi in Tempo Reale)
Chiamante Scambio Chiamato
inizio
tono libero
componi n.
...
instradamento
tono attesa
tel suona
risposta
stop attesa
stop attesa
a
b
c
d
d
{b-a < 1 sec.}
{c-b < 10 sec.}
{d-d < 5 sec.}
Il ritardo dovuto
alluso della rete
A questo punto inizia
la conversazione
Esercizio Esercizio
Si definisca un semplice Sequence Diagram per
modellare il prelievo di denaro, supponiamo 200
Euro, da uno sportello Bancomat
Sequence Diagram Sequence Diagram
(Processi Concorrenti e Attivazioni) (Processi Concorrenti e Attivazioni)
Obj1:C1
op()
doit(z)
Obj3:C3
Obj2:C2
Obj4:C4
[x>=0] foo(x)
[x<0] bar(x)
doit(w)
more()
Messaggi Messaggi
Sincroni
Chi invia il messaggio aspetta la conclusione
delloperazione richiesta (chiamata di procedura)
Asincroni
Equivalenti a qualche forma di comunicazione tra
processi)
Chi invia il messaggio continua, senza aspettare la
conclusione delloperazione richiesta (comunicazione
fra processi)
Riassumendo Riassumendo
Uno scenario pu essere rappresentato per mezzo di
un Interaction Diagram
I Sequence Diagram mettono pi enfasi sulla
sequenza delle operazioni e possono indicare
lesistenza dei diversi oggetti
I diagrammi vanno completati con commenti testuali
per fornire ulteriori dettagli
Politecnico Politecnico
di Milano di Milano
Class Diagram Class Diagram
Class Diagram Class Diagram
Definiscono la visione statica di un dominio
classi
relazioni tra classi
associazione (uso)
generalizzazione (ereditariet)
aggregazione (contenimento)
forse il modello pi importante perch definisce
gli elementi base del dominio
Classi Classi
Una classe composta da tre parti
nome
attributi (lo stato)
metodi (il comportamento)
Professore
nome
cognome
create()
delete()
Professore
create()
delete()
Professore
nome
cognome
Professore
Catalogo Corsi
Professore
Elenco Iscritti
Corso Studente
Cartella Studente
Le Le classi classi Trovare Trovare le le classi classi e e gli gli oggetti oggetti
Dove guardare
osservazioni di prima mano, ascoltare attivamente,
considerare risultati precedenti e altri sistemi,
leggere a volont, prototipi
Cosa cercare
strutture, altri sistemi, dispositivi, cose ed eventi
ricordati, ruoli, procedure operative, luoghi ed unit
organizzative
Cosa considerare
memoria e comportamento necessari, molteplicit di
attributi e di istanze, attributi e metodi sempre
presenti, requisiti del dominio
Esempio della biblioteca Esempio della biblioteca
Identificazione Identificazione di classi e di classi e oggetti: i oggetti: i candidati candidati
La biblioteca organizzata in settori, a ciascuno dei quali
corrisponde un argomento (storia, narrativa, saggistica, arti
pratiche, scienza, tecnologia, fantascienza, musica, ecc.).I settori
contengono documenti di vario genere: libri, riviste, materiale audio
(dischi, cd, cassette) e video (cassette e video dischi). I documenti
risiedono in scaffali opportunamente numerati.
La biblioteca concede prestiti (fino a 15 giorni) e un singolo rinnovo
di una settimana. I prestiti sono concessi agli utenti registrati. La
registrazione effettuata automaticamente su domanda dell'utente.
Se la restituzione dei documenti in prestito non avviene entro
termine stabilito la biblioteca avverte lutente tramite sollecito. Se
anche questa azione non sortisce effetto, si passa alla sospensione
dal prestito dellutente.
Esempio della biblioteca Esempio della biblioteca
Identificazione di classi e oggetti: i candidati Identificazione di classi e oggetti: i candidati
Non tutti i documenti sono prestabili, per vari
motivi (sono rari o preziosi o devono essere sempre
consultabili). Le riviste contengono collezioni di
articoli, che sono memorizzati singolarmente nel
database di sistema. Le riviste sono presenti in
copia unica e non sono prestabili.
I documenti sono descritti da appositi cartellini
contenuti in schedari che gli utenti possono
consultare. Ogni cartellino riporta: titolo, autore,
editore e anno di emissione del documento ed altre
informazioni per ciascun documento.
Esempio della biblioteca Esempio della biblioteca
Identificazione di classi e oggetti: i candidati Identificazione di classi e oggetti: i candidati
biblioteca settore argomento documento
libro rivista mat. audio disco
CD cassetta video video cassetta
video disco scaffale prestito giorno
rinnovo settimana utente azione
termine registrazione collezione articolo
database copia cartellino schedario
titolo autore editore informazioni
anno descrizione restituzione sollecito
sospensione sistema
Esempio della biblioteca Esempio della biblioteca
Linsieme Linsieme iniziale di classi iniziale di classi
biblioteca settore argomento documento
libro rivista audio disco
CD cassetta video video cassetta
video disco scaffale prestito giorno
rinnovo settimana utente azione
termine registrazione collezione articolo
database copia cartellino
schedario
titolo autore editore informazioni
anno descrizione restituzione sollecito
sospensione sistema
Attributi Attributi
Un attributo una caratteristica della classe
Gli attributi non hanno identit
Ogni attributo deve essere definito in modo preciso
Attributi buoni per Studente
Nome, Cognome,
Attributi cattivi
CorsiScelti
nome
cognome
Professore
et
id
nome
cognome
Professore
et
Attributi (cont.) Attributi (cont.)
Gli oggetti avranno una loro identit, non bisogna
aggiungerla
Codice fiscale?
Attributi (cont.) Attributi (cont.)
Nomi che non sono diventati classi
Durante la definizione delle classi stesse
Conoscenza del dominio applicativo
Persona (ambito bancario)
nome, cognome, codiceFiscale, numeroConto
Persona (ambito medico)
nome, cognome, allergie, peso, altezza
Attributi Derivati Attributi Derivati
Calcolati, 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
et = f(dataDiNascita, oggi)
area, perimetro = f(vertici)
Attributi Derivati (cont.) Attributi Derivati (cont.)
Persona
dataNascita : Date
/ et : int
1..*
Divisione
1..*
Persona
1..*
lavora
Azienda
1..*
/ impiega
{et = oggi - dataNascita}
Operazioni (Metodi) Operazioni (Metodi)
Un operazione una trasformazione applicabile ad
unistanza di una classe
Tutte e sole le operazioni rilevanti per il dominio
applicativo
Bancario
ricevePrestito, riceveCredito, apreConto
Medico
faEsame, prendeMedicina, vaOspedale
Classi Classi
(Visibilit) (Visibilit)
Professore
{abstract}
+ nome: String
# cognome: String
- et: integer = 32
+ visualizza()
- scegliCorso()
Professore
nome: String
cognome: String
et: integer
visualizza()
scegliCorso()
Professore
Template
Class
Instantiated Class
<base>
Base
Classi Parametriche Classi Parametriche
(Template) (Template)
Modo sintetico per definire un insieme di classi
simili
Le singole classi si ottengono istanziando i parametri
contenuti nella definizione
Vettore
T,k:integer
Vettore<char,3>
Pentagono
<<bind>> (Vertici,5)
Istanziazione Istanziazione
<<utility>>
Matematica
log(int):real
sin(Ang):real
sqrt(int):real
power(real, int): real
Classi Utility Classi Utility
Contengono metodi di classe e non di istanza (come
i metodi static di Java)
Interfacce Interfacce
Definiscono il comportamento esterno di una classe
String
uguale(String):Boolean
hash():Integer
HashTable
Hashable
Comparable
Associazioni Associazioni
Unassociazione definisce un canale di
comunicazione bidirezionale fra le due classi
La molteplicit definisce il numero di istanze che
prendono parte alla relazione
I link sono istanze delle associazioni
Un link connette due oggetti
Un'associazione connette due classi
Corso
CartellaStudente
appare
Associazioni Associazioni
Unassociazione indica una relazione tra classi
ad esempio persona che lavora per azienda
Unassociazione deve avere un nome
Il nome solitamente un verbo (un etichetta al
centro della linea che definisce lassociazione)
Corso Studente
3 .. 10 0..*
Molteplicit Molteplicit
La molteplicit dice:
Se lassociazione obbligatoria oppure no?
Il numero minimo e massimo di oggetti che possono
essere relazionati ad un altro oggetto
segue
Molteplicit (cont.) Molteplicit (cont.)
1
Esattamente 1
*
zero o pi
0..1
zero o uno
m..n
entro gli estremi specificati
Persona Azienda
lavora
Impiegato DatoreDiLavoro
1..* 0..1
Ruolo Ruolo
Definisce il ruolo svolto nellassociazione
Utente Directory
proprietario
utente autorizzato
contenente
conteneuto
0..*
0..*
0..* 0..*
0..1
Ruolo (cont.) Ruolo (cont.)
Il ruolo diventa importante quando una classe
coinvolta pi volte nella stessa associazione
Studente Corso
Frequenza
percentuale
profitto
1..* 1..*
Attributi Attributi
Alcune propriet potrebbero appartenere
allassociazione e non alle parti coinvolte
Classe A Classe B
Classe C
Classe D
operationZ()
<<friend>>
<<friend>>
<<calls>>
<<instantiates>>
Dipendenza Dipendenza
Relazione che indica una dipendenza tra classi (es.
se cambia la definzione di B, questo influenza A, C,
D)
Corso Curriculum
1..*
Aggregazioni Aggregazioni
Le aggregazioni sono una forma particolare di
associazione. Una parte in relazione con un
oggetto (part-of)
Slider
Panel
Button
Window
1
2
1
1
1
1
scrollbar
body
close
2
1 1
1
1
1
Composizioni Composizioni
Una relazione di composizione unaggregazione forte
Le parti componenti non esistono senza il contenitore
Creazione e distruzione avvengono nel contenitore
I componenti non sono parti di altri oggetti
Composizione Composizione
(Notazioni Alternative) (Notazioni Alternative)
body:Panel
scrollbar: Slider
close: Button
Window
1
1
2
body
scrollbar
close
Window
1
1
2
Slider
Panel
Button
Aggregazione
Corso
Precedenze
Parte
Associazioni riflessive Associazioni riflessive
Unassociazione riflessiva se coinvolge oggetti
della stessa classe
Indicano oggetti multipli della stessa classe che sono
in relazione fra loro
Persona
Studente
Professore
Ereditariet (Generalizzazione) Ereditariet (Generalizzazione)
Esplicita eventuali
comportamenti comuni
possibile dover:
Aggiungere nuove
propriet alle classi
Ridefinire/modificare
operazioni esistenti
ruolo
ruolo
Veicoli
Terrestri
Veicoli
Veicoli
PropUmana
Macchina Bicicletta BarcaARemi
{propulsione}
{overlapping}
{superficie}
Ereditariet Ereditariet
(Sottoclassi non Disgiunte) (Sottoclassi non Disgiunte)
Classi Astratte Classi Astratte
Poligono
{abstract}
Cerchio
Figura
{abstract}
Triangolo
Quadrato
Catalogo Corsi
Professore
Elenco Iscritti
Corso Studente
Cartella Studente
Precedenze
Registrazione Corsi Registrazione Corsi Soluzione Soluzione con con molteplicita molteplicita
Catalogo Corsi
Professore
Elenco Iscritti
Corso Studente
Cartella Studente
3..10
Precedenze
0..*
0..*
1..*
1..*
1..1
1..1
1..1
1..1
1..1
0..*
1..*
Riassumendo Riassumendo
Le classi sono lelemento fondamentale di qualsiasi
sistema ad oggetti
In un Class Diagram si definiscono
Le classi
Le relazioni fra classi
Associazioni
Aggregazioni
Specializzazioni/generalizzazioni
Politecnico Politecnico
di Milano di Milano
Uso Uso di di UML UML nella nella creazione creazione di di un un documento documento di di
progetto progetto
Struttura di un documento di Struttura di un documento di
descrizione dei requisiti descrizione dei requisiti
Costituito da 3 parti:
Descrizione del dominio applicativo
Descrizione dei requisiti
effetti che il software deve esercitare sul dominio
applicativo.
Specifica (design dellinterfaccia) della macchina da
realizzare.
Descrizioni e specifiche possono essere scritte in
qualsiasi linguaggio (informale, semi-formale,
formale)
Come Come procedere procedere? ?
Descrizione del dominio applicativo
Class diagram per identificare i fatti e le relazioni tra
fatti
Uso degli Actor per identificare gli attori che operano
nel dominio applicativo
Descrizione dei requisiti
Use case per descrivere gli effetti che il software
deve esercitare sul dominio applicativo
Specifica dei requisiti
Scenari ed interaction diagram
Esempio Esempio 1: 1: sviluppo sviluppo di di unagenda unagenda
cooperativa cooperativa
Unazienda di piccole dimensioni commissiona ad
una software house lo sviluppo di unagenda
destinata alluso da parte dei dipendenti
Lagenda deve consentire agli utenti di tenere
traccia degli appuntamenti e delle scadenze
importanti che li riguardano
Lagenda deve supportare gli utenti
nellorganizzazione di meeting interni allazienda
Vincoli che possono originare requisiti extra-
funzionali (vedremo dopo)
I dipendenti dellazienda sono dotati di PC con
sistema operativo Windows.
Lazienda cablata con una rete Ethernet a 100Mb
Use case Use case
proponente partecipante
Fissa Riunione
Inserisci impegno
Visualizza agenda
Cancella impegno
utente
partecipante
Proponi riunione
proponente
GestisciRisposta
Dettaglio di Fissa Riunione
Rappresentazione del dominio del
problema: il diagramma delle classi
Appuntamento
Personale Lavoro
Impegno
Impiegato Agenda
0..n
1..n
0..n
1..n
1 1
Riunione
Ha a disposizione
1 1
ImpegnoConDurata
Scadenza Data
Inizia
Finisce
Rappresentazione del dominio del problema:
scenario di proposta di una riunione
: proponente
agenda :
Agenda
agendaCol lega :
Agenda
directoryAgende
: partecipante
proponi riunione
AgendaDi(nome)
proponi riunione
Proponi riunione
conferma riunione
conferma riunione
noti fica conferma
Esempio 2: un sistema di controllo Esempio 2: un sistema di controllo
A simple system:
a controller uses a sensor with an analog-to-digital
converter to acquire information.
The controller then uses an actuator to affect its
environment.
The system may use a temperature sensor to
activate either a heater or a fan for closed-loop
control.
Additionally, it may use a pressure sensor to provide
information about a gas line that it uses to control a
valve with a stepper motor.
Rappresentazione del dominio del
problema: il diagramma delle classi
Esercizio Esercizio
Completare il documento dei requisiti aggiungendo
gli opportuni use cases e scenari