Progettazione di Sistemi di TLC
basati sull’informatica
Laboratorio
Prof. Claudio Becchetti
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-1
Lezione 1
Progettazione: “il problema tipico”
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-2
Regole del corso
 la maggior parte del lavoro si svolge in classe
 le lezioni sono interattive
 Colui che chiede una domanda può diventare uno
stupido per 5 minuti, colui che non la chiede sarà
uno stupido per sempre (prov. cinese)
 Creare il cartellino badge
 la valutazione finale non si basa sulle risposte
date in classe
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-3
metodo di valutazione
 la valutazione si basa su:
 voto di gruppo,
 Voto di coppia (tesina)
 Esame individuale
 Tesina: il vostro background ?
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-4
Preparazione individuale
 corsi sulla progettazione del software
 corsi su TLC
 conoscenze Object oriented
 conoscenze linguaggi di programmazione
 Elettronica
 bioingegneria
 problem solving ?
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-5
Testi di riferimento
 TLC
 Reti di Computer,Tanenbaum A. , Prentice Hall Int.
1996 (anche in italiano)
 Digital Communications, Proakis J. G., McGraw-Hill
 Software
 Software Engineering, Pressmann Roger S. ,
McGraw-Hill, (anche in italiano)
 UML Distilled: Applying the Standard Object Modeling
Language, Martin Fowler, Kendall Scott, AddisonWesley (anche in italiano)
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-6
Altri testi
 Articoli
 “No silver bullets, essence and accidents of
software engineering”, Brooks F. P., Computer (Apr. 1987).
 “Building bug-free O-O software: An introduction to
Design by Contract”, Meyer B., available in
http://www.eiffel.com/

Jézéquel J.M., Meyer B.,
“Design by contract: the lesson
of Ariane”, IEEE Computer, 30, No. 2, pp. 129-130 (Jan. 1997) also
available in http://www.eiffel.com/
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-7
testi opzionali

Analisi Strutturata dei Sistemi, E. Yourdon. Jackson
Italia, 1990

The C++ Programming Language, third edition,
Stroustrup B., Addison-Wesley (1997). .

Speech Recognition : Theory and C++
implementation, Becchetti C., Prina L., John Wile & Sons,
1999

Borland C++ 4.0 Object-Oriented Programming,
Cantù M., Tendon S., Random House/Borland Press (1995)

Cline M. P., Lomow G. A., C++ Faqs, Addison Wesley
(1995).
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-8
Presentazione del corso
 Corso di progettazione
 focus sulla progettazione in generale
 focus
sulla progettazione del software
 focus sui sistemi di telecomunicazione (TLC)
 focus su Object Oriented (OO) e C++
 Perché focus sulla progettazione ?
 La progettazione è uno strumento per il problem
solving
–
esempio paolo
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-9
a cosa vi serve veramente questo corso ?

Non progetterete mai ?

Non svilupperete mai il sw ?

non vi occuperete mai di TLC ?

Il C++ sarà superato

l’object oriented non serve ?

Dopo un mese dall’esame vi sarete dimenticati tutte le nozioni
apprese ?
 Il corso è indirizzato alla progettazione secondo le
esigenze del mondo del lavoro

progettare significa risolvere i problemi (problem solving)
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-10
cosa vede una società da un neolaureato
anche brillante




un elemento grezzo da formare
a seconda dei lavori occorrono nell’ordine dei 12
mesi perché un neolaureato sia “operativo”
nei primi 12 mesi il neolaureato non è in grado di
fare quasi nulla per l’industria
per rendere operativo un neolaureato, occorre
molto addestramento (“training on the job” )
 l’organizzazione cerca di insegnare il problem
solving nella fase di addestramento
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-11
cosa vorrebbe l’industria da un
neolaureato
 capacità
di analizzare e risolvere problemi/lavori
complessi e nuovi
 capacità di rispettare i vincoli del problema (tempi,
costi e risorse disponibili)
 capacità di rispettare i vincoli per risolvere il
problema (tempi costi e risorse disponibili)
 a prescindere dal settore di impiego (software, tlc,
gestionale, marketing, ...)
 Quindi
-> problem solving:
 capacità
di portare a termine con profitto un lavoro in
maniera autonoma
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-12
Problem solving e capacità di progettare:
serve solo nel lavoro?
Problema risolto
lavoro concluso
Lavoro da fare
Problema da risolvere
tempi
Vincoli
Lavoro ben fatto
soluzione adeguata
costi
risorse
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-13
Problem solving: dove ?
 creare
un sistema tlc
 organizzare una vacanza
 Aprire un ristorante
 produrre un software
 creare un nuovo prodotto
 organizzare una festa
 organizzare una vacanza
 lasciare la ragazza?
 Il problem solving serve ovunque si presenti un
problema/ lavoro:


1) importante
2) di complessità non banale
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-14
Problem solving e progettazione
 Ogni volta che dobbiamo risolvere un problema o
fare un lavoro importante occorre:
 progettare il lavoro/ la soluzione
 Progettare significa stabilire:
 cosa
bisogna fare
 Come implementarlo
 In che tempi
 Con che risorse
 Come verificare cosa si è implementato
 la capacità di problem solving si acquisisce
imparando a progettare
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-15
La progettazione e il corso
 lo scopo del corso è di insegnare a progettare
 vi verranno insegnate nel corso le tecniche di
progettazione che dovrete applicare a casi concreti
 le
tecniche di progettazione servono solo nel mondo
del lavoro ?
 le
tecniche di progettazione servono solo nel campo
del software TLC ?
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-16
Praticone o Progettista ?
 Esempio:
 Le istruzioni della cinepresa nuova:
Leggete le istruzioni o usate subito la cinepresa ?
Fine task
100 %
?
% Funzionamento
compreso
0%
Tempo
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-17
Task problemi e progettazione
In tempo ?
task
da fare
Concluso ?
Problema
da risolvere
task
da fare
Bene ?
Rispetta i vincoli
(costi)?
Concluso
!!
Problema
da risolvere
•Tempi rispettati
•costi rispettati
•funzioni coperte
con adeguata qualità
Tecniche di progettazione
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-18
Esempio:
 Esempio del viaggio
 la mia organizzazione della settimana bianca
 e io intanto prenoto (esempio rosanna)
 “Usa la testa non le gambe”
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-19
Schema di un problema
controlla
Cliente
fornisce
affida
Input
Task
vincoli
Progetta , pianifica, esegue
Output
Le definizioni ?
esecutore
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-20
Definizioni
 Task
 tutto le operazioni che devo compiere per ottenere
l’output
 Input
 tutto ciò che posso o devo prendere dall’ambiente
esterno per portare a termine il task,
 informazioni
(dati, scadenze, costi, tempi)
 risorse (mezzi fisici, persone, soldi)
 Vincoli
 possono impedire la soluzione del task (vincoli
incrociati)
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-21
Definizioni (output e test)
 Output
 il risultato del mio lavoro:
 informazioni
, servizi, mezzi trasformati , documenti,
progetti, software ...
 Test
 metodi implementati da me o dal mondo esterno
per verificare che l’output sia adeguato
 Cliente
 chi mi chiede di:
 risolvere
un problema
 definire delle soluzioni
 portare a termine una attività
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-22
identificazione di input output e task e test
 Esercitazione
 creare una tabella a 5 colonne : nome del task
come di seguito, input , vincoli, descrizione task,
output, test)
 creazione

video gioco software
lavoro di gruppo
 progettazione
di un telefonino
 produzione di un telefonino
 organizzazione di un concerto
 organizzazione di una vacanza con un gruppo di
amici
 quale è la differenza fra input e vincolo ?
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-23
L’Invariante di Input e vincoli
 tutti i problemi implicano
 tempi di realizzazione (cioè pianificazione controllo)
 costi (budget a disposizione)
 risorse (umane, materiali)
 per affrontare un problema/ progettazione occorre
definire sempre chiaramente i tre aspetti
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-24
Esempio
SENIOR PROJECT MANAGER:Descrizione
E' responsabile della stesura, sviluppo e gestione di progetti
informatici incentrati sulle applicazioni di Rete per l'interazione
Internet, Intranet ed Extranet.
In particolare il suo ruolo prevede:




la definizione, con il cliente, del piano di lavoro e delle
modalità di collaborazione nell'ambito di system
integration;
l'analisi e la valutazione delle diverse componenti del
progetto (costi, tempi e risorse);
la gestione del team interno di lavoro e degli eventuali
partner;
la verifica dei risultati raggiunti.

7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-25
I dati di input sono esaustivi ?
 Se il problema non è banale, i dati di input non
sono mai sufficienti per avere un task univoco e
una soluzione univoca.
 Questo è la causa più frequente di incapacità di
portare a termine un task soprattutto in problemi
mai affrontati
 altra causa di paralisi nel portare a termine un
task sono i vincoli incrociati
 Come si procede ?
Le assunzioni !!
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-26
Assunzioni
 L’assunzione deve essere:
 plausibile nel contesto del task
 esplicitata (deve essere menzionata da qualche parte)
 Le assunzioni sono spesso collegate ai soldi e sono
fondamentali per la buona riuscita di un progetto (ref. il
registro delle assunzioni)
 Le assunzioni servono a
 Ridurre il numero di possibilità di design
 Semplificare
 Limitare e vincolare il task (l’oggetto non farà questo)
 Definire delle preferenze (p.es. linguaggio usato)
 eliminare i vincoli
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-27
Esercizio:
 identificare le assunzioni dei precedenti casi
 creazione video gioco software




progettazione di un telefonino
produzione di un telefonino
organizzazione di un concerto
organizzazione di una vacanza con un gruppo di
amici
 nel corso vi sono volutamente (come nella realtà) case
study con dati di input incompleti o vincoli incrociati
 E’ fondamentale che voi identifichiate e tracciate le
assunzioni per evitare input incompleti o vincoli incrociati
 E’ compito del committente accettare le assunzioni
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-28
Schema del corso
 parte 1 ; le fasi della progettazione
 parte 2 : la progettazione strutturata
 parte 3: la progettazione a oggetti e classi
 parte 4: la progettazione object oriented
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-29
le fasi della progettazione
 Progettare “X” significa stabilire:
 1: Mission (cosa è “X” e purché faccio “X” )
 2: Analisi (cosa fa “X” )
 3: Design (come realizzo “X” )
 4: Implementazione (“X” realizzato)
 5: Test (“X realizzato funziona ? È adeguato ?” :
 Rispetta
design (è come lo volevo implementare)
 Rispetta analisi (fa ciò che avevo progettato di fargli
fare)
 Rispetta la mission (soddisfa il motivo per cui lo
avevo fatto)
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-30
Capacità acquisite nella prima lezione
 dato un problema qualsiasi:
 identificare
 input
 vincoli
 output
 task
 cliente
 test

individuare input incompleti/vincoli incrociati

definire assunzioni plausibili individuare i rischi
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-31
Lezione 2
le fasi della progettazione:
la mission, l’analisi
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-32
Task problemi e progettazione
In tempo ?
task
da fare
Concluso ?
Problema
da risolvere
task
da fare
Bene ?
Rispetta i vincoli?
Concluso
!!
Lavoro ben fatto
soluzione adeguata
Problema
da risolvere
Tecniche di progettazione
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-33
Perché progettare ?
 Progettare è frustrante
 All’inizio si raggiungono risultati più lentamente
 È una attività impegnativa perché richiede forte uso
di attività concettuale invece si tende a prediligere
attività celebrale “manuale”
 Stanca più velocemente
 progettare è vincente
 Garantisce il risultato giusto in tempi certi
 Il tempo impiegato è molto inferiore rispetto
all’approccio da “code and fix”.
 “Usa la testa e non le gambe”
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-34
Perché imparare a progettare
 Secondo la letteratura scientifica, un personale ben addestrato può
lavorare fino a 25 volte di più rispetto ad un personale non
sufficientemente adeguato nell'ambito del software. (Negli altri
settori il differenziale di produttività si limita ad un fattore 4 ).
 La differenza di prestazioni fra due operatori del software è spesso
dovuta ad una differente capacità di progettazione
 Riduzione del ciclo di vita del software: come è ripartito fra le varie fasi ?
Maintainance 62%
Testing 15%
Implementation 7%
Analysis 6%
Design 5%
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-35
Non progettare nel software e nelle TLC
 Non progettare significa:

I tempi per concludere un task possono dilatarsi
all’infinito (comune nella codifica del software)

Non si sa mai quando si finisce (per fare il 5% del
lavoro occorre il 95 % del tempo ?)

La qualità del prodotto è bassa, richiede
normalmente rilavorazioni per correggere errori

Il prodotto può essere gestito solo da chi lo ha
creato
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-36
Praticone o Progettista ?
 Esempio:
 Le istruzioni della cinepresa nuova:
Leggete le istruzioni o usate subito la cinepresa ?
Fine task
100 %
?
% Funzionamento
compreso
0%
Tempo
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-37
Parte prima: le fasi della progettazione
 Progettare “X” significa stabilire:
 1: Mission (cosa è “X” e purché faccio “X” )
 2: Analisi (cosa fa “X” )
 3: Design (come realizzo “X” )
 4: Implementazione (“X” realizzato)
 5: Test (“X realizzato funziona ? È adeguato ?” :
 Rispetta
design (è come lo volevo implementare)
 Rispetta analisi (fa ciò che avevo progettato di fargli
fare)
 Rispetta la mission (soddisfa il motivo per cui lo
avevo fatto)
 Case study: la penna
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-38
Le fasi della progettazione
Mission
Analisi
Design
Implement.
Test
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-39
1: Mission
 Indica la meta, la direzione e lo scopo del task che si vuole
compiere
 È espresso in forma concisa (max 3 righe)
 Serve a eliminare i problemi di framework

Esempio di framework (es. la Russia in sede)
 E’ un “contratto” con il cliente:
 Va concordato con il cliente
 È focalizzato sui bisogni del cliente
è difficile da individuare
è difficile da seguire
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-40
Lost the mission-> Fired !
 Perdere la mission può far licenziare (esempio)
 la mission deve essere sintetica: le mission nelle aziende
 IBM
At IBM, we strive to lead in the creation, development and manufacture of the
industry's most advanced information technologies, including computer systems,
software, networking systems, storage devices and microelectronics.
And our worldwide network of IBM solutions and services professionals translates
these advanced technologies into business value for our customers

Coca cola
 The
Coca-Cola Company exists to benefit and refresh
everyone who is touched by our business.
 Esercizio:
 trovare alcune mission la Fiat, Xerox, IBM, HP, un teatro
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-41
Esempi di mission


Il cliente chiede: progettami una penna
Mission: progettare un oggetto in grado di scrivere
indelebilmente sulla carta
 Quali assunzioni ?
 Esercizio definire la mission per
 la progettazione di un centralino telefonico per piccole
aziende,
 la progettazione di gioco per play station,
 la progettazione di un video telefono mobile.
 Quali assunzioni ?
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-42
2: Analisi
 Specifica che cosa deve fare il prodotto/servizio
indicato nella mission
 Deve discendere ed essere coerente con la
mission

Esempio di incoerenza fra mission e analisi (la coppia faffi)
 E’ una lista di requisiti secondo il punto di vista
del cliente utilizzatore

se non si è capaci di fare analisi non si è
capaci di codificare il software
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-43
I requisiti
 I requisiti sono un qualcosa desiderato dal cliente
espresso in forma di frase testuale




I requisiti dovrebbero essere numerati
I requisiti dovrebbero essere testabili
I requisiti dovrebbero essere univoci,non
sovrapponibili, non ambigui
I requisiti dovrebbero coprire completamente i
desiderata del cliente
 i requisiti sono definiti dall’analista in base alle
richieste del cliente, o sono direttamente forniti
dal cliente
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-44
Esempio di requisiti
 Le penna:
 Mission: progettare una penna per scrivere sulla
carta
 Requisiti:
1.
2.
3.
4.
5.
La penna dovrà scrivere per almeno un chilometro
di carta
La penna dovrà avere un costo di produzione
inferiore a 1 €
La penna dovrà avere una impugnatura giudicata
comoda per almeno il 70% degli utilizzatori
La penna dovrà scrivere in inchiostro blu o rosso
La penna dovrà funzionare fra 0° e i 40°
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-45
Validazione dei requisiti
 Il cliente dà spesso requisiti ambigui/incompleti
 l’analista li trasforma in modo che i requisiti siano:
 numerati
 testabili
 Definire


un test per i precedenti requisiti
Non sovrapposti
Coprano completamente i desiderata del cliente
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-46
Esempio di requisiti non corretti
 Dash lava più bianco !: come si testa ?
 Requisiti:
1.
2.
3.
4.
5.
6.
La penna dovrà scrivere a lungo
La penna dovrà scrivere per almeno un chilometro
di carta
La penna dovrà costare poco
La penna dovrà avere un costo di produzione
inferiore a 1 €
La penna dovrà avere una impugnatura adeguata
La penna dovrà scrivere bene
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-47
Criteri aggiuntivi di validazione dei requisiti
 Fattibilità
 Siamo in grado di farlo ?
 Abbiamo il tempo i soldi le capacità le persone giuste (il
caso ATC USA)
 Accettabilità
 Ci conviene farlo ?
 Otteniamo qualcosa di soddisfacente come performance
 Vulnerabilità
 qualsiasi cosa che può andare male andrà male (Murphy)
 Quali sono i rischi / conseguenze delle nostre scelte ?
 Essendo pessimisti cosa può andar male e se va male
quali sono le conseguenze
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-48
Gli errori dell’analista
 Esempio di errore
 esempio della penna e del software ()
 Errore tipico e grave:



inserire nell’analisi di X come va fatto X (=design)
quali sono le implicazioni di questo errore ?
L’errore ha impatto su costi tempi e risorse ?
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-49
Gli errori dell’analista 2
 esempio: una società di consulenza invia un ingegnere
neolaureato ad un corso approfondito di analisi UML
 l’ingegnere fa grande esperienza di analisi
 la società di consulenza deve effettuare un lavoro di
informatizzazione presso una azienda e decide di inviare
l’ingegnere per il lavoro di analisi
 quali sono i problemi che incontrerà l’ingegnere ?
 1:esempio
 2:esempio
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-50
Il dominio del problema e della soluzione
Dominio del problema
mission
analisi
Dominio della soluzione
design
implementazione
Mondo delle
soluzioni
problema
analista
sviluppatore
cliente
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-51
conclusione sugli errori
 l’analista non deve confondere analisi con design
 l’analista deve conoscere il dominio del problema
 l’analista deve conoscere il dominio della
soluzione
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-52
Esercizio ricapitolativo sulla analisi
 Definire mission e analisi per i seguenti problemi,
per ogni requisito definire un test







Uno scanner
Una videocamera
Un telefonino
Una radio
Un programma di posta elettronica
Un ristorante
Una festa
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-53
Progetto di una festa
 Il committente richiede un festa
 L’organizzatore chiede come organizzarla
 Il committente risponde: l’importante è che ci
divertiamo

Requisito: divertirsi ?
 Testabile

? (il cliente mi paga se si è divertito ?)
Cosa fa l’organizzatore ?
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-54
Obiettivi raggiunti
 dato un problema qualsiasi bisogna essere in
grado di:

definire la mission (max 3 righe):

definire l’analisi:
 definire
i requisiti
–
evitare i requisiti scorretti
– definire i test dei requisiti
 evitare
gli errori dell’analista:
non immettere il design nell’analisi
– capire il dominio del problema
– capire il dominio della soluzione
–
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-55
Lezione 3
Design
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-56
fallimento dei progetti software
 in che cosa falliscono ?
 funzioni, tempi e costi previsti
 quanti progetti falliscono ?

16% successo

53% successo solo parziale

31% fallimento e cancellazione
–
Studio dello Standish Group 1994 su 8380 progetti
 le percentuali di fallimento sono superiori per
progetti di dimensioni maggiori
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-57
Perché i progetti falliscono
1: Requisiti incompleti
13.1%
2: mancato coinvolgimento dell’utente
12.4%
3: Mancanza di risorse
10.6%
4: Attese irrealistiche
9.9%
5: mancanza di supporti della direzione
9.3%
6: cambio di requisiti
8.7%
7: mancanza di pianificazione
8.1%
8: non serve più
7.5%
 A quali fasi riconducete i fallimenti
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-58
tipologie dei requisiti
 tipologie di requisiti
 funzionali
 tecnologici
 Temporali
 economici
 organizzativi
 prestazionali
 relativi all’utilizzo
 alla sicurezza
deve fare
deve usare tec.
deve metterci
deve costare
deve essere organizzato
deve essere usato
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-59
Storia di un progetto
Ciò che ha chiesto
il cliente
Ciò che ha realizzato
la fabbricazione
Ciò che ha capito
il commerciale
Come hanno rimediato
ai problemi
i responsabili del montaggio
Come ha risolto
il problema
la progettazione
Ciò che realmente
voleva il cliente
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-60
Il dominio della soluzione: il design
Dominio del problema
mission
analisi
Dominio della soluzione
design
implementazione
Mondo delle
soluzioni
problema
analista
sviluppatore
cliente
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-61
3: Design
mission
mission
design
 Dato il “cosa deve fare X” (=analisi)
 il design specifica come deve essere fatto,
 il design è il progetto dell’implementazione
 È come il progetto della casa (costruireste una casa
senza il progetto)
 Il design discende dall’analisi (tracciamento)
 Per ogni requisito o gruppo di requisiti occorre
specificare un insieme di specifiche di realizzazione
 Attenzione alle incoerenze: (es. la coppia)
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-62
Esempio di design (la penna)
 R1: La penna dovrà scrivere per almeno un chilometro di carta


D1: la penna conterrà 10 ml di inchiostro
D2: la penna sarà a sfera con sfera di acciaio inox
 R2: La penna dovrà avere un costo di produzione inferiore a 1 €

D3:i materiali di produzione saranno …
 R3: La penna dovrà avere una impugnatura giudicata comoda per
almeno il 70% degli utilizzatori

D4: L’impugnatura sarà di tipo …
 R4: La penna dovrà scrivere in inchiostro blu o rosso

D5…
 R5: La penna dovrà funzionare fra 0° e i 40° gradi

D6 l’inchiostro sarà di tipo
 R6: La penna dovrà avere un costo di produzione inferiore a 1 €

D1, D2, D3,D4,...
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-63
Esercizio a squadre sul design
 Definire mission e analisi e design e test :
 organizzare un ristorante
 progettare uno scanner
 progettare uno una videocamera
 valutare criticamente il lavoro altrui
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-64
Validazione del design
 E’ in linea con l’analisi ?
 tracciare ogni componente del design sui requisiti di analisi
 Fattibilità
 Siamo in grado di farlo ?
 Abbiamo il tempo i soldi le capacità le persone giuste
 Accettabilità
 Ci conviene farlo ?
 Otteniamo qualcosa di soddisfacente come performance
 Vulnerabilità
 qualsiasi cosa che può andar male andrà male
 i rischi / conseguenze della scelta implementativa
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-65
Design iterativo
 Il primo design è fondamentale ma è sbagliato !!
 Il design (specialmente nel sw) va fatto
considerando una prima soluzione , migliorandola
successivamente
5 design: quasi inutile
3 design: si svolta
100%
6 design: inutile
efficacia
4 design: si migliora poco
2 design
tempo
1 design:
sbagliato ma utile
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-66
Migliorare il design
 le iterazioni successive possono migliorare:
 tempi di sviluppo
 risorse



impiegate
costi di sviluppo
qualità del prodotto
affidabilità del prodotto
 le iterazioni successive possono ridurre i rischi:
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-67
Esercizio a squadre sul design
 Definire mission e analisi e design e test :
 progettare uno un telefonino
 comprare un telefonino
 progettare una radio per la macchina
 organizzare una festa
 valutare criticamente il lavoro altrui
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-68
Implementazione
 Realizzazione del progetto di design
 Per il software coincide con la codifica
 Deve essere in linea con il design
 Se vi sono problemi con il design, aggiornare il
design e eventualmente l’analisi
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-69
Test
 La fase di test serve a verificare se ho raggiunto obiettivi:
 E’ composta da Verifica e Validazione
 Verifica :stiamo costruendo un prodotto bene
(implementazione soddisfa il design)
 Si definiscono una serie di test per verificare che il
prodotto funziona
 Validazione :
 stiamo costruendo il prodotto giusto ?
 è efficacie ?
 È quello che ha chiesto il cliente
–
si definiscono una serie di test che discendono dai requisiti e si
verificano
– Verificare che i requisiti di analisi del cliente siano soddisfatti nel
prodotto finale
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-70
Esempio di test
 Verifica
 la penna non si deve rompere quando scrive
 non
discende dai requisiti del cliente ma comunque è
un test importante di funzionalità)
 Validazione

R5: La penna dovrà funzionare fra 0° e i 40°
 Metto
la penna in un frigo a 0° per 10 minuti e provo a
scrivere
 Metto la penna in un forno a 40° per 10 minuti e
provo a scrivere
 Il test è collegato a collaudi, pagamenti e alle
penali

esempio: Penali al secondo
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-71
Esercizi
 definire mission, analisi, design,
implementazione, test per i seguenti problemi:






un videotelefono
un sistema di domotica
un dvd recorder
un ponte radio
un modem telefonico
un ristorante
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-72
Come si gestisce un progetto / problema
 definire gli obiettivi del progetto
 creare il piano del progetto (inizio progetto)
 controllare il progetto (durante il progetto)
 chiudere il progetto
start
Eseguo
task
fine
pianifico
monitorizzo
Aggiorno
piani
nuovi
piani
Quando
finisce ?
controllo
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-73
Fasi per la creazione di un piano
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-74
Creare il piano del progetto
 prima di iniziare un progetto si deve definire una
pianificazione:
 la pianificazione scompone l’attività principale in
sottoattività
 per ogni attività




nome
responsabile
data inizio/ fine (ore uomo richieste/ disponibili)
vincoli temporali prerequisiti
 i piani vengono descritti attraverso un Gannt
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-75
Esercitazione sui Gannt
 I Gannt
 scadenze, barre attività vincoli
 Creare il Gannt di un video gioco
 definire i task, risorse, ...
 modifiche sul Gannt
 cambiare risorse
 livellare
 uso delle risorse
 attività critiche
 percorso critico
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-76
Gannt di un video gioco
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-77
Controllo
 definire le misure per il controllo
 misurare periodicamente
 percentuale di lavoro finito
 la curva di fine
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-78
controllo
 definire le misure di controllo
 verificare le previsioni con le misure attuali
 i ritardi: strategie di recovery
 curve di risposta
100%
controlli
% concluso
tempo
fine
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-79
Problemi della pianificazione/controllo
 pianificazione
 valutazione delle prestazioni della risorsa
 disponibilità risorse
 percorso critico
 compatibilità con le scadenze
 priorità
 vincoli
 forward scheduling backward scheduling
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-80
Verificare i ritardi
Fine reale
previsione
100%
controlli
% concluso
Misura reale
oggi
Fine
teorica
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-81
Esercitazioni
 Definire il piano per ottenere l’output della esercitazione
 definire i tempi e i controlli
 il piano degli esami
 il piano per la progettazione del software
 il piano per la progettazione dell’organizzazione festa
 il piano organizzazione vacanze
 il piano start up di un ristorante
 il piano di start up di un sito web
 domande





quali assunzioni
quali dati di input
quali vincoli
come si controlla, quali misure
i tempi sono stati rispettati
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-82
Fasi del progetto: Harvard Business School
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-83
Obiettivi raggiunti
 Da ricordare
 le fasi della progettazione Mission, analisi, design,
implementazione, test
 cosa è la mission
 la differenza fra analisi e design (cioè cosa fare e come
realizzarlo)
 il test
 essere capaci di :
 definire le fasi di progetto e il test per un generico problema
 definire la pianificazione di un progetto
 definire le metodologie di controllo
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-84
Lezione 4
Ciclo di vita del software
gerarchie
Più che una disciplina o un corpo di conoscenza, l’ingegneria è
un modo di affrontare un problema
Scott Whitmire
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-85
Modelli del processo software
 Ciclo di vita di un progetto software = Modello e
sequenza delle attività di sviluppo.
 Tipi di modelli:




Il modello sequenziale lineare (“modello a cascata”
o gran design)
Il modello basato sulla prototipazione
Il modello RAD (Rapid Application Development)
Modelli evolutivi
–
–
–
Il modello incrementale
Il modello a spirale
Il modello ad assemblaggio di componenti
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-86
Modello “a cascata”: Grand design
Strutturazione e modellazione del sistema e
dei dati (livello sistema)
Analisi dei
requisiti sw.
dominio delle informazioni,
funzionalità,
comportamento, prestazioni,
interfacce
Progettazione
strutture di dati, architettura
del software, interfacce,
algoritmi delle operazioni
Il software è una parte di un sistema più
ampio. Sono necessarie un’analisi e una
progettazione di alto livello per
raccogliere tutti i requisiti, da cui il
software utilizza solo una parte.
Codifica
Collaudo
codice
Problemi:
• i progetti reali non si conformano allo schema sequenziale
• ogni modifica nello schema può causare confusioni
• non può essere governata l’incompletezza dei requisiti
• versione funzionante solo verso la fine del progetto
• “stati bloccanti” per colpa della sincronizzazione tra le attività o tra i membri del team
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-87
Sviluppo evolutivo
 Problema:
 non c’è tempo di fornire una release che copra tutti i requisiti
 i requisiti sono incompleti
 soluzione
 sviluppo in sequenza prototipi sempre più completi
 i prototipi implementano sottoinsiemi di requisiti non
congelati
 il cliente approva o modifica le implementazioni del prototipo

Vantaggi dello sviluppo iterativo






È pianificato e gestito
È prevedibile
Permette variazioni dei requisiti più facilmente
È basato su prototipi eseguibili evolutivi e non solo documentati
Implica il cliente nell’arco dell’intero processo
È guidato da rischi
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-88
Sviluppo evolutivo del software
1. Non c’è tempo per una versione completa però dobbiamo uscire sul
mercato.
2. Esiste un nucleo di requisiti di sistema ma i dettagli delle estensioni non
esistono ancora.
Soluzione: modello di processo per un prodotto che evolve nel tempo
Definire l’output
del sistema
Specificare
l’incremento del
sistema
Costruire
l’incremento del
sistema
Rilasciare
l’incremento del
sistema
Collaudare
l’incremento del
sistema
Sistema è
completo?
Completare il
rilascio del sistema
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-89
Modello incrementale
Utile quando la disponibilità del personale è
insufficiente a garantire l’implementazione
completa. Si comincia con un piccolo team. Il
team accresce se l’accoglienza è positiva.
Strutturazione del sistema
e dei dati
Stadio 1
Proget
tazione
Analisi
Codifica
Collaudo
Consegna dello
stadio 1
Implementa solo
una parte dei requisiti
Stadio 2
Proget
tazione
Analisi
Stadio 3
Analisi
Codifica
Proget
tazione
Collaudo
Codifica
Consegna dello
stadio 2
Collaudo
Consegna dello
stadio 3
Si partizionano i requisiti in tre stadi a seconda delle priorità
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-90
Modello a spirale
Sei attività portanti
(task region):
Comunicazioni
con il cliente
Asse dei punti di
entrata
Pianificazione
Analisi dei rischi
Valutazione da parte
del cliente
Strutturazione
Costruzione e rilascio
Il modello abbina la natura iterativa della
prototipazione e gli aspetti controllati e
sistematici del modello sequenziale.
Progetti di sviluppo di nuove idee
Progetti di sviluppo di un nuovo prodotto
Progetti di miglioramento di un prodotto
Progetti di manutenzione di un prodotto
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-91
Modello ad assemblaggio di componenti
Analisi dei rischi
Pianificazione
Comunicazioni
con il cliente
Valutazione da
parte del cliente
Individuazione
componenti
candidati
Costruzione
n-esima iterazione
del sistema
Ricerca
componenti nella
libreria
Inserimento nuovi
componenti nella
libreria
Estrazione
componenti
disponibili
Strutturazione
Costruzione e rilascio
Costruzione
componenti non
disponibili
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-92
modello di sviluppo RAD
 consentono un tempo di sviluppo molto ridotto
 il modello di sviluppo è :
 analisi
 Business modelling: definizione dei flussi informativi e dei
processi
–
Data modelling
– process modelling


design / implementation
 application generation: direttamente con il tool di 4g. Molto
del codice è già implementato nel tool
testing
 limitato perchè la maggior parte del software è già
sviluppato
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-93
Pro&contro del modello RAD
 Pro
 velocità
 affidabilità (il codice è per la maggior parte già sviluppato)
 contro
 adatto solo se esiste un tool RAD che implementa la maggior
parte del codice per l’applicazione specifica
 non è facile particolareggiare il codice
 non è facile migliorare le performances
 spesso si ignorano i passi fondamentali della progettazione e
quindi il risultato è disastroso
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-94
Riuso o sviluppo ex novo ?
 Spesso sono disponibili componenti utili per lo
sviluppo: debbono essere utilizzati ?
Sviluppo ex novo
costo
riuso
lavoro da effettuare in creazione o modifica
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-95
Riuso o sviluppo ex novo ?
 Riduzione del ciclo di vita del software: come è
ripartito fra le varie fasi ?
Maintainance 62%
Analysis 6%
Testing 15%
Implementation 7%
Design 5%
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-96
Analisi del costo di sviluppo
 le fasi di debugging/ maintainance hanno il
costo maggiore
 Occorre impostare Analisi, design e codifica
nel progetto in modo da minimizzare il costo
di debugging testing e manutenzione
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-97
Quale modello
 La scelta del modello è influenzata da vari fattori:
 formalismo del progetto
 disponibilità di risorse
 disponibilità dei requisiti
 disponibilità del cliente
 disponibilità di codice preesistente RAD tools
 tempi e costi
 risorse (numero e skill)
 esercizio: quale modello scegliereste ?
 modello a cascata, evolutivo, incrementale, a
spirale, assemblaggio di componenti, RAD
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-98
Lezione 4
Seconda parte: gerarchie
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-99
Regola fondamentale: Divide et Impera !
 Cosa avevano capito i Romani
 La mente umana è molto limitata

il caso di Paolo d. (problema finanziario) /alessia M(psicologia nei
problemi complessi)
Problema
affrontabile
Problema
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-100
Implicazioni del divide et impera
 divido il problema in sottoproblemi risolvibili
 risolvo un sottoproblema alla volta considerando
gli altri risolti
 definire sottoproblemi mi aiuta a dividere il lavoro
fra più persone
Problema
da affrontare
Problema dato per risolto
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-101
Dal sistema al dettaglio:gerarchie e zoom
Divide et Impera !
 Se il sistema è troppo complesso:




1) si definisce l’analisi del sistema (gerarchia uno)
2) si definiscono i sottosistemi (gerarchia due)
3) si definiscono le interfacce
4) si procede sul sottosistema come se fosse un
sistema
 mission,
analisi, design, ....
 Se i sottosistemi sono ancora troppo complessi
 si crea una altra gerarchia
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-102
Gerarchie
Gerarchia 2
Mondo
Interfaccia 1
 Dato un sistema connesso con
l’esterno da interfacce esterne,
una gerarchia è composta da:



sottosistemi che partizionano il
sistema
interfacce che connettono i
sottosistemi
le interfacce esterne che
connettono i sottosistemi con
il mondo esterno
sistema
Interfaccia 2
Interfaccia 1
sottosist
sottosist
Interfaccia 3
Interfaccia 4
sottosist
Gerarchia 2
Gerarchia 3
sottosist
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-103
Come si definiscono i moduli?
 Principio di massima coesione e minimo
accoppiamento

un modulo deve essere:
 internamente
–
massimamente coeso
deve offrire un servizio completo
 minimamente
accoppiato con gli altri moduli
–
le interfacce devono essere di minima consistenza
– i moduli sono minimamente interdipendenti
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-104
Coesione ed accoppiamento
Casuale
Temporale
Logica
Bassa
Di comunicazione
Procedurale
Funzionale
Sequenziale
Spettro della coesione
“Dispersivo”
Alta
“Concentrato”
Nessun
Accoppiamento a
Accoppiamento
Accoppiamento
accoppiamento
template
esterno
di contenuto
diretto
Accoppiamento di
Accoppiamento
Accoppiamento
dati
di controllo
comune
Bassa
Spettro dell’accoppiamento
Alta
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-105
Esempio di definizione dei moduli
 definire un design corretto e scorretto di
modularizzazione
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-106
Determinazione del numero dei moduli
 Quanti moduli devo fare
 il costo di un sistema è proporzionale alla complessità
 la complessità è data dalla somma della complessità
intramodulo e della complessità delle interfacce intermoduli
Complessità
totale
Complessità &
costo
Complessità
delle interfacce=
costo di integrazione
Complessità
dei modulo
= costo per modulo
Maggiore Granularità (+ moduli +piccoli)
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-107
Esempio: progettazione di una auto
 auto troppo complessa! Divide et impera !

Definisco la mission
 progettare

una auto utilitaria per l’Italia
Definisco analisi del sistema auto
–
R_auto_1: deve raggiungere la velocità di almeno 140
– R _auto_ 2: deve lavorare fra -15° e +45° gradi
– R _auto_ 3: deve frenare da 50 km/h a 0km/h in 10 sec
– R _auto_ 4: deve avere 4 posti comodi

definisco i sottosistemi (gerarchia di primo livello)
 motore,

carrozzeria, ruote,freni, volante, cambio
definisco le interfacce fra i sottosistemi
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-108
Esempio auto gerarchia primo livello
 Motore
 Mission: muovere la macchina
 R_auto_1:
–
R_Moto_1: deve avere 6000 giri con 4KW potenza
 R_auto_2:
–
deve raggiungere la velocità di almeno 140
deve lavorare fra -15° e +45°
R_Moto_2: non deve congelare sotto i 15° ...
 Il motore come sistema è ancora troppo
complesso-> espandiamo la gerarchia:

motore composto da :
–
refrigerazione,
– propulsione
– centralina di controllo
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-109
La gerarchia del progetto auto
auto
motore
refrigeramento
propulsione
ruote
controllo
freni
comandi utente
acceleratore
volante
cambio
frizione
 La struttura è simile ad WBS (work breakdown
structure)
 legami con OBS (organization) e CBS (cost)
 Quali sono le interfacce ?
 esercizio
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-110
Regole per la costruzione della gerarchia
 le interfacce definiscono i rapporti fra due
sottosistemi
 le interfacce devono essere coerenti fra diverse
gerarchie
 tutti i requisiti di un sistema si devono tradurre in
requisiti per i sottosistemi
 lo zoom fra le varie gerarchie deve essere
coerente a livello di interfacce e di contenuti
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-111
Coerenza delle gerarchie per le interfacce
 gerarchia 1
 contenuto Lazio
 interfacce esterne: A1 Napoli, A1 Firenze
 gerarchia 2 province del Lazio (Roma LT, FR, VT, RI)
 interfacce
esterne: A1 Napoli (LT), A1 Firenze (FR)
 interfacce interne: RM LT (Pontina,...), RM VT
(Cassia,...)
 gerarchia 3 comuni di Latina (Formia, Gaeta, ... LT,
FR, VT, RI)
 non si devono perdere le interfacce
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-112
Gli attori
 gli attori sono tutte le entità che interagiscono
con il sistema
 gli attori sono collegati con il sistema attraverso
interfacce esterne
 gli
attori non sono solo persone
 per il sottosistema motore gli attori sono:
 cambio(interfaccia albero di trasmissione)
 comandi utente (interfaccia filo acceleratore)
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-113
diagramma funzionale con attori
comanda
Auto
Gerarchia
1° livello
interagisce
strada
guidatore
Comandi
auto
comanda
Gerarchia
2° livello
guidatore
interagisce
Motore
freni
Ruote
strada
cambio
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-114
diagramma funzionale: 3° gerarchia
Comandi
auto
gestisce Motore
Comandi
auto
Gerarchia
3° livello
Invia rotazione
cambio
girano
interagisce
Ruote
strada
bloccano
Invia rotazione
Freni
cambio
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-115
diagramma funzionale: 4° gerarchia
Comandi
auto
Comandi
auto
gestisce
gestisce
Motore
Gerarchia
3° livello
Invia rotazione
cambio
Gerarchia
4° livello
controllo
propulsore
Invia rotazione
cambio
refrigeramento
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-116
Requisiti di interfaccia
 Gerarchia 1: interfacce esterne
 comanda,
interagisce:
 Gerarchia 2: interfacce interne
 girano,
bloccano, invia rotazione
 Gerarchia 3: interfacce interne
 ....
 Le interfacce di una gerarchia vengono ereditate e
eventualmente approfondite nelle gerarchie
successive
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-117
Esercizio: il ristorante
 definire mission
 analisi di sistema
 requisiti del sistema
 attori
 interfacce esterne e requisiti associati
 definire i sottosistemi (gerarchia di primo ordine)



definire interfacce interne fra sottosistemi e requisiti associati
associare interfacce esterne a sottosistemi
analisi di sottosistema
 requisiti del sottosistema
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-118
Esercitazione: sistema gestione ordini e
conto per ristoranti
 mission: progettare un sistema informatico che
gestisca gli ordini e il conto finale per ogni
ristorante

analisi di sistema
 requisiti
del sistema
 attori
 interfacce

esterne e requisiti associati
definire i sottosistemi (gerarchia di primo ordine)
 definire
interfacce interne fra sottosistemi e requisiti
associati
 associare interfacce esterne a sottosistemi
 analisi di sottosistema
–
requisiti del sottosistema
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-119
Obiettivi raggiunti
 saper scegliere il giusto modello di sviluppo in base alla
tipologia di problema modello a cascata, evolutivo,
incrementale, a spirale, assemblaggio di componenti, RAD
 per ogni problema essere capaci di :

individuare sottoproblemi (gerarchia 1)
 determinare
i sottosistemi in base alla complessità di
interfaccia e di modulo
 definire
interfacce esterne e interne
 associare e definire i sottorequisiti

iterare il processo per il numero di gerarchie
necessarie
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-120
Lezione 5
Strumenti per l’analisi:
diagrammi E/R, Use case, diagrammi di Eventi
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-121
Le fasi della progettazione
Mission
Analisi
Design
Implement.
Test
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-122
Attività di analisi
 1: Comprensione del problema: Requisiti.
 2: utilizzo del sistema dal punto di vista utente:

casi d’uso.
 3: Modellazione.
 4: Specifica
 5: Riesame.
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-123
Attività di analisi : 1
 1: Comprensione del problema: Requisiti.


Per mezzo di interazioni e discussioni con l’utente e dello studio
della specifica del sistema e del piano di progetto (se ci sono!),
l’analista raccoglie i requisiti. Requisiti: descrizione di come il cliente
o l’utente desidera essere il sistema.
Gli elementi acquisiti dall’analista sono:
 una descrizione del sistema
 gli attori del sistema
 gli obiettivi del sistema
 le funzioni del sistema
 gli attributi del sistema
 2: utilizzo del sistema dal punto di vista utente: casi
d’uso.

Per chiarire a sè e all’utente il sistema da progettare, l’analista
descrive come il sistema verrà utilizzato dall’utente attraverso i casi
d’uso. I casi d’uso sono scenari che mostrano l’utilizzo del sistema
in situazioni specifiche
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-124
Attività di analisi : 2
 3: Modellazione. L’analista definisce le gerarchie e per ogni
gerarchia definisce i vari modelli: Entità/Relazione, funzionale, di
stato del sistema nel tentativo di cogliere la struttura, il
contenuto informativo, il flusso di dati e del controllo e
l’operatività del sistema.
 4: Specifica. Requisiti, gerarchie, casi d’uso, modelli E/R,
funzionali e di stato vengono riorganizzati e ingegnerizzati.
 5: Riesame. Verifica della completezza, consistenza e accuratezza
della specifica.
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-125
Strumenti di analisi
 1: Comprensione del problema 
 Requisiti 
 2: utilizzo del sistema dal punto di vista utente
 casi d’uso
 3 Modellazione
 gerarchie 
 modelli dei dati (E/R)
 modelli funzionali 
 diagrammi di stato
 diagrammi di interazione (eventi)
 4: Specifica.
 ingegnerizzazione dei requisiti e modelli
 5 Riesame
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-126
Modello dei dati
 Descrive il mondo dei dati del problema dal punto
di vista dell’analisi
 elementi di un modello di dati:

oggetti
 attributi:sono
i dati di un oggetto (=descrivono
caratteristiche oggetto e riferimenti ad altri oggetti)

Relazioni: definiscono i collegamenti fra oggetti
(approfondite quando si parlerà di OO)
 cardinalità:
numero di occorrenze di oggetti in una
data relazione
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-127
Diagrammi E/R (notazione UML)
Oggetto
attributo 1 (ID)
Oggetto
*
Nome relazione 1..n
attributo 2..
attributo 1 (ID)
attributo 2..
Relazione
Cardinalità
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-128
sistema gestione ordini e conto per
ristoranti (GOCR):gerarchia 1°
 mission: progettare un sistema informatico che gestisca gli ordini e il
conto finale per ogni ristorante
Cameriere
Ordini/ conti
Cliente
Sistema Gocr
Stampa conto
cassa
Ordini pietanze
cucina
Analisi scorte
Gestore approvvigionamenti
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-129
GOCR gerarchia 2° (struttura dati)
Pietanza
ID
tipo
Prezzo
Singolo ord.
ID ordine
id pietanza
quantità
Ordine
ID
ID Tavolo
Ora
gestito da
Quantità richiesta
ID Pietanza
ID ingrediente
quantità
ingrediente
ID
quantità disponibile
Tavolo
ID
stato
Cameriere
ID
Nome
 conoscete MS Access ?
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-130
Modello in Access
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-131
Diagrammi E/R
 Criteri per la progettazione
 Eliminazione dei percorsi ciclici
 Eliminare la ridondanza dei dati /relazioni
 Cercare la max semplicità
 Minimo
numero di records e di relazioni
per il problema in esame




Non confondere E/R (senza info di tempo ) con
l’ordine di inserimento dei dati nel database
Navigare le relazioni per valutare coerenza
Valuare i costi di scelta “ attributo o relazione ?”
NO colonne variabili !!!
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-132
GOCR gerarchia 2° (struttura funzionale)
conti
cassa
Gestione conti
Cameriere
Preparazione pietanze
Calcolo conti
Gestione ordini
cucina
Gestione scorte
Gestore scorte
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-133
Diagramma di stato (stato tavoli) :
esercitazione
 Convenzione UML
start
transizione
stato
 Esercizio:
 identificare stati
 libero,attesa
ordine, in_consumazione,richiesta
conto

identificare transazioni
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-134
esercizio: segreteria telefonica
 Identificare gli stati e le conessioni
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-135
Use cases: Attori
•Qualunque entità esterna interagisce con il sistema,
persone o macchine, può essere modellizzato come un
attore.
•Analizzando gli attori ci concentriamo su come il
sistema sarà utilizzato e non su come sarà progettato o
implementato.
attore
Professore
Utente sistema
generalizzazione
Studente
Cliente
di banca
Operatore
Gestore
BANCOMAT
Sistema paghe
Sistema
informatico
bancario
Operatore
Bancomat
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-136
Casi d’uso (use cases)
 Specifica di un comportamento di un sistema





Un caso d’uso è una modo per utilizzare un sistema, o anche
uno schema del suo comportamento.
Descrive una sequenza di azioni, che il sistema compie come
risposta agli stimoli ricevuti da vari attori e che si materializza
in un risultato che serve ad un attore, quello che ha iniziato il
caso.
I casi d’uso non contengono informazioni su come realizzare
il comportamento.
Un caso d’uso descrive un’insieme di sequenze, in cui
ciascun sequenza rappresenta l’interazione di entità esterne
al sistema (attori) con il sistema..
Un caso d’uso rappresenta un requisito funzionale dell’intero
sistema.
 É il contenuto base del manuale utente
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-137
Casi d’uso
semplice nome
nome con percorso
Gestione Corso
Gestione Piano Corsi
Circoscrizione::Richiesta di certificato
Casi d’uso e attori:
• Ciascun caso d’uso può coinvolgere più attori.
• Un attore può utilizzare più casi d’uso dello stesso sistema.
• Per ciascun attore, si deve identificare come vuole utilizzare il sistema. Ciascun
modo di utilizzare il sistema diventa un caso d’uso.
Fuori sistema
Cliente della
banca
Sistema
Prelevamento
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-138
Come scrivere un caso d’uso
1. Viene creato un documento di flusso di eventi per ciascun caso d’uso. Il
documento è scritto dal punto di vista di un attore.
2. Viene dettagliato che cosa il sistema deve rilasciare all’attore quando il caso
d’uso viene eseguito.
Tipicamente il documento contiene:




Come inizia e come si termina il caso d’uso
Il flusso normale di eventi
I flussi alternativi di eventi
I flussi straordinari di eventi
Caso d’uso
Nome:
Attori:
Precondizioni:
Descrizione:
Eccezioni:
Postcondizioni:
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-139
Descrizione di un caso d’uso
Caso d’uso: Prelevamento contanti
Quando un cliente inserisce la carta, la macchina legge il codice della carta e
verifica se si tratta di una carta valida. Se non è valida, viene espulsa.
Altrimenti si richiede il codice PIN (5 cifre) al utente.
Quando il codice PIN è stato inserito, la macchina verifica se il codice è corretto
per la carta utilizzata. In caso positivo, la macchina richiede che tipo di
transazione si desidera eseguire.
Quando il cliente seleziona Prelevamento contanti la macchina richiede la
somma. Sono permessi soltanto multipli di Lit. 50.000.
Quando ….
Un caso d’uso descrive un insieme di sequenze di eventi che sono varianti nello
stesso caso. Ciascuna sequenza rappresenta uno scenario. Uno scenario è
rispetto ad un caso d’uso come un‘istanza rispetto alla classe.
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-140
Caso d’uso: telefonata con il telefonino
Caso d’uso
Nome:
telefonata con tel
Attori:
utente
Precondizioni:
acceso
Descrizione:
Eccezioni:
Postcondizioni:

l’utente spinge i bottoni del numero di telefono richiesto

l’utente aspetta un segnale

se libero aspetta ....
...
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-141
Diagrammi di casi d’uso
I diagrammi di casi d’uso sono creati per la modellizzazione della vista relativa al
utillizo di un sistema. Di solito questa vista riguarda la modellizzazione del
ambiente e dei requisiti del comportamento del sistema o del sottosistema.
Richiesta Corso
Studente
Professore
Gestione Piano di Studi
Sistema di tasse
Gestione Piano Semestrale
Operatore
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-142
Identificazione dei casi d’uso
1 . Identificare gli attori.
2 . Intervistare gli utenti tipici.
3 . Riflettere sui modi fondamentalmente differenti in cui ciascun attore utilizza il
sistema.
4 . Raggruppare gli scenari che sono simili e di cui l’utente parla come fossero
variazioni su una unica tema.
5 . Denominare i casi d’uso e fornire una descrizione.
6 . Cercare i frammenti comuni tra i differenti casi d’uso e fattorizzarli in casi
d’uso di base e aggiunti.
7 . Associare ad ogni caso d’uso un valore di priorità.
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-143
Diagramma di eventi
 I diagrammi di interazioni descrivono come vengono
realizzati i casi di uso attraverso le interazioni tra oggetti.
 Contiene un’insieme di messaggi interscambiati tra un
insieme di oggetti in un certo ambiente (sistema,
sottosistema ecc.) per compiere un certo obiettivo.
 Quando due oggetti sono connessi tra loro, c’è un caso
d’interazione.
 Un diagramma di sequenze di eventi mostra un’interazione
disposta in ordine cronologico. Mostra gli oggetti
partecipanti all’interazione con le loro linee di vita e i
messaggi scambiati in ordine cronologico.
 Messaggio - specifica di una comunicazione tra oggetti, trasporta
un’informazione con l’intento di far scattare un’attività
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-144
Diagrammi di sequenze (=di eventi)
Oggetto
“Linea della vita”
dell’oggetto
rappresenta
l’esistenza
dell’oggetto o
dell’attore
Attivazione
Mostra il periodo
in cui un oggetto
realizza un’azione
etichetta
telefonino
utente
interlocutore
Digita numero
a
{b-a<2sec}
Messaggio
- call
- return
- send
- create
- destroy
b
chiamata
Risposta libera
risponde
Voce inter.
c
{b-a<5sec}
b
Vincolo
Tempo della
transizione
Tempo
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-145
sistema gestione ordini e conto

mission: progettare un sistema informatico che gestisca gli ordini e il conto finale per ogni
ristorante
 definire diagramma eventi per ordini e conto finale
Cameriere
Ordini/ conti
Cliente
Sistema Gocr
Stampa conto
cassa
Ordini pietanze
cucina
Analisi scorte
Gestore approvvigionamenti
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-146
Esercizio diagramma di sequenza per
GOCR
Sistema Gocr
Cameriere
cucina
cassa
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-147
Esercizio: organizzo una vacanza
agenzia
amici
Tour operator
IO
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-148
Obiettivi raggiunti
 Da ricordare
 gli strumenti a disposizione dell’analisi
 Per qualsiasi problema essere capaci di :
 individuare gli strumenti di analisi necessari
 E/R, Use case diagramma di eventi, diagramma funzionale,
diagrammi di stato
 individuare quali strumenti non sono necessari
 saper modellare la struttura dati (E/R)
 saper definire gli stati interni se necessario (diag. di stato)
 saper creare un caso d’uso
 saper descrivere una interfaccia con gli strumenti di analisi
7/1/03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza”
-149