Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -1 7/1/03 Progettazione di Sistemi di TLC basati sull’informatica Prof. Claudio Becchetti Laboratorio
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -1
7/1/03
Progettazione di Sistemi di TLCbasati sull’informatica
Prof. Claudio Becchetti
Laboratorio
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -2
7/1/03
Lezione 1
Progettazione: “il problema tipico”
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -3
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -4
7/1/03
metodo di valutazione
la valutazione si basa su: voto di gruppo, Voto di coppia (tesina) Esame individuale
Tesina: il vostro background ?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -5
7/1/03
Preparazione individuale
corsi sulla progettazione del software corsi su TLC conoscenze Object oriented conoscenze linguaggi di programmazione Elettronica bioingegneria problem solving ?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -6
7/1/03
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, Addison-Wesley (anche in italiano)
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -7
7/1/03
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/
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -8
7/1/03
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).
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -9
7/1/03
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 paoloesempio paolo
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -10
7/1/03
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)
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -11
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -12
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -13
7/1/03
Problem solving e capacità di progettare: serve solo nel lavoro?
Lavoro da fare
Problema da risolvere
Vincolitempi
costi
risorse
Problema risoltolavoro concluso
Lavoro ben fattosoluzione adeguata
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -14
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -15
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -16
7/1/03
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 ?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -17
7/1/03
Praticone o Progettista ?
Esempio: Le istruzioni della cinepresa nuova:
Leggete le istruzioni o usate subito la cinepresa ?
Tempo
% Funzionamento compreso
0 %
100 %
Fine task?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -18
7/1/03
Task problemi e progettazionetask
da fare
Problema da risolvere
Concluso ?
In tempo ?
Bene ?
Rispetta i vincoli(costi)?
•Tempi rispettati•costi rispettati•funzioni coperte con adeguata qualità
Concluso !!
taskda fare
Problema da risolvere
Tecniche di progettazioneTecniche di progettazione
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -19
7/1/03
Esempio:
Esempio del viaggio la mia organizzazione della settimana bianca
e io intanto prenoto (esempio rosanna)
“Usa la testa non le gambe”
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -20
7/1/03
Schema di un problema
Cliente
InputInput OutputTask
fornisce
controlla
Progetta , pianifica, esegue
affida
vincoli
esecutore
Le definizioni ?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -21
7/1/03
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)
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -22
7/1/03
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à
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -23
7/1/03
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 ?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -24
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -25
7/1/03
Esempio
SENIOR PROJECT MANAGER:DescrizioneE' 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.
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -26
7/1/03
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 !!
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -27
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -28
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -29
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -30
7/1/03
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)
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -31
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -32
7/1/03
Lezione 2
le fasi della progettazione: la mission, l’analisi
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -33
7/1/03
Task problemi e progettazionetask
da fare
Problema da risolvere
Concluso ?
In tempo ?
Bene ?
Rispetta i vincoli?
Lavoro ben fattosoluzione adeguata
Concluso !!
taskda fare
Problema da risolvere
Tecniche di progettazioneTecniche di progettazione
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -34
7/1/03
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”
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -35
7/1/03
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% Analysis 6%
Implementation 7% Design 5%
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -36
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -37
7/1/03
Praticone o Progettista ?
Esempio: Le istruzioni della cinepresa nuova:
Leggete le istruzioni o usate subito la cinepresa ?
Tempo
% Funzionamento compreso
0 %
100 %
Fine task?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -38
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -39
7/1/03
Le fasi della progettazione
Mission
Analisi
Design
Implement.
Test
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -40
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -41
7/1/03
Lost the mission-> Fired !
Perdere la mission può far licenziare (esempio) la mission deve essere sintetica: le mission nelle aziende
IBMAt 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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -42
7/1/03
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 ?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -43
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -44
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -45
7/1/03
Esempio di requisiti
Le penna: Mission: progettare una penna per scrivere sulla
carta Requisiti:
1. La penna dovrà scrivere per almeno un chilometro di carta
2. La penna dovrà avere un costo di produzione inferiore a 1 €
3. La penna dovrà avere una impugnatura giudicata comoda per almeno il 70% degli utilizzatori
4. La penna dovrà scrivere in inchiostro blu o rosso 5. La penna dovrà funzionare fra 0° e i 40°
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -46
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -47
7/1/03
Esempio di requisiti non corretti
Dash lava più bianco !: come si testa ? Requisiti:
1. La penna dovrà scrivere a lungo
2. La penna dovrà scrivere per almeno un chilometro di carta
3. La penna dovrà costare poco
4. La penna dovrà avere un costo di produzione inferiore a 1 €
5. La penna dovrà avere una impugnatura adeguata
6. La penna dovrà scrivere bene
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -48
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -49
7/1/03
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 ?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -50
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -51
7/1/03
Il dominio del problema e della soluzione
mission analisi design implementazione
Dominio della soluzioneDominio del problema
cliente
analista
problema
sviluppatore
Mondo dellesoluzioni
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -52
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -53
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -54
7/1/03
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 ?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -55
7/1/03
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 scorrettievitare i requisiti scorretti– definire i test dei requisitidefinire i test dei requisiti
evitare gli errori dell’analista:– non immettere il design nell’analisinon immettere il design nell’analisi– capire il dominio del problemacapire il dominio del problema– capire il dominio della soluzionecapire il dominio della soluzione
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -56
7/1/03
Lezione 3
Design
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -57
7/1/03
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 progettiStudio dello Standish Group 1994 su 8380 progetti
le percentuali di fallimento sono superiori per
progetti di dimensioni maggiori
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -58
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -59
7/1/03
tipologie dei requisiti
tipologie di requisiti funzionali deve fare tecnologici deve usare tec. Temporali deve metterci economici deve costare organizzativi deve essere organizzato prestazionali relativi all’utilizzo deve essere usato alla sicurezza
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -60
7/1/03
Storia di un progetto
Ciò che ha chiesto il cliente
Ciò che ha capito il commerciale
Come ha risolto il problema
la progettazione
Ciò che ha realizzato la fabbricazione
Come hanno rimediatoai problemi
i responsabili del montaggio
Ciò che realmente voleva il cliente
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -61
7/1/03
Il dominio della soluzione: il design
mission analisi design implementazione
Dominio della soluzioneDominio del problema
cliente
analista
problema
sviluppatore
Mondo dellesoluzioni
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -62
7/1/03
3: 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)
mission mission design
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -63
7/1/03
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,...
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -64
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -65
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -66
7/1/03
Design iterativo
Il primo design è fondamentale ma è sbagliato !! Il design (specialmente nel sw) va fatto
considerando una prima soluzione , migliorandola successivamente
tempo
efficacia
1 design: sbagliato ma utile
2 design
3 design: si svolta
4 design: si migliora poco
5 design: quasi inutile
6 design: inutile100%
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -67
7/1/03
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:
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -68
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -69
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -70
7/1/03
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 si definiscono una serie di test che discendono dai requisiti e si verificanoverificano
– Verificare che i requisiti di analisi del cliente siano soddisfatti nel Verificare che i requisiti di analisi del cliente siano soddisfatti nel prodotto finaleprodotto finale
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -71
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -72
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -73
7/1/03
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
pianifico
Eseguo task fine
monitorizzoAggiorno
pianinuovi piani
Quando finisce ?
controllo
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -74
7/1/03
Fasi per la creazione di un piano
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -75
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -76
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -77
7/1/03
Gannt di un video gioco
ID Nome attività Durata Inizio Fine PredecessoriNomi risorse
1 progetto di un video gioco 125 g 30/01/03 23/07/03
2 analisi 25 g 30/01/03 05/03/03
3 raccolta richieste cliente 10 g 30/01/03 12/02/03 claudio
4 definizione dei requisiti 10 g 13/02/03 26/02/03 claudio
5 ingegnerizzazione dei requisiti5 g 27/02/03 05/03/03 claudio
6 design 60 g 06/03/03 28/05/03 2
7 definizione piattaforma linguaggio5 g 06/03/03 12/03/03 claudio
8 definizione primo design 20 g 13/03/03 09/04/03 claudio
9 validazione primo design 5 g 10/04/03 16/04/03 claudio
10 prototipo 10 g 17/04/03 30/04/03 claudio
11 secondo design 20 g 01/05/03 28/05/03 claudio
12 implementazione 30 g 29/05/03 09/07/03 6
13 modulo utente 10 g 29/05/03 11/06/03 claudio
14 modulo intelligenza 20 g 12/06/03 09/07/03 claudio
15 test 10 g 10/07/03 23/07/03 12 claudio
16 manuale utente 5 g 30/01/03 05/02/03 francesco
17 test finale 0 g 23/07/03 23/07/03 15
18 collaudo cliente 0 g 30/06/03 30/06/03
claudio
claudio
claudio
claudio
claudio
claudio
claudio
claudio
claudio
claudio
claudio
francesco
23/07
30/06
19/01 02/02 16/02 02/03 16/03 30/03 13/04 27/04 11/05 25/05 08/06 22/06 06/07 20/07 03/08 17/08feb 03 mar 03 apr 03 mag 03 giu 03 lug 03 ago 03
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -78
7/1/03
Controllo
definire le misure per il controllo misurare periodicamente percentuale di lavoro finito la curva di fine
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -79
7/1/03
controllo
definire le misure di controllo verificare le previsioni con le misure attuali i ritardi: strategie di recovery curve di risposta
tempo
% concluso
100%
fine
controlli
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -80
7/1/03
Problemi della pianificazione/controllo
pianificazione valutazione delle prestazioni della risorsa disponibilità risorse percorso critico compatibilità con le scadenze priorità vincoli forward scheduling backward scheduling
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -81
7/1/03
Verificare i ritardi
oggi
% concluso
100%
Fine teorica
controlli
previsione
Misura reale
Fine reale
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -82
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -83
7/1/03
Fasi del progetto: Harvard Business School
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -84
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -85
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -86
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -87
7/1/03
Strutturazione e modellazione del sistema e dei dati (livello sistema)
Analisi dei requisiti sw. Progettazione Codifica Collaudo
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
Modello “a cascata”: Grand designIl 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.
dominio delle informazioni, funzionalità, comportamento, prestazioni, interfacce
strutture di dati, architettura del software, interfacce, algoritmi delle operazioni
codice
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -88
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -89
7/1/03
Definire l’output del sistema
Specificare l’incremento del
sistema
Costruire l’incremento del
sistema
Collaudare l’incremento del
sistema
Rilasciare l’incremento del
sistema
Sistema è completo?
Completare il rilascio del sistema
Sviluppo evolutivo del software1. 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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -90
7/1/03
Strutturazione del sistemae dei dati
AnalisiProget tazione
Codifica Collaudo
Stadio 1
Consegna dello stadio 1
AnalisiProget tazione
Codifica CollaudoStadio 2 Consegna dello stadio 2
AnalisiProget tazione
Codifica CollaudoStadio 3 Consegna dello stadio 3
Modello incrementaleUtile quando la disponibilità del personale è insufficiente a garantire l’implementazione completa. Si comincia con un piccolo team. Il team accresce se l’accoglienza è positiva.
Implementa solo una parte dei requisiti
Si partizionano i requisiti in tre stadi a seconda delle priorità
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -91
7/1/03
Modello a spirale
Il modello abbina la natura iterativa della prototipazione e gli aspetti controllati e sistematici del modello sequenziale.
Sei attività portanti(task region):
Pianificazione
Analisi dei rischi
Strutturazione
Costruzione e rilascio
Comunicazioni con il cliente
Valutazione da parte del cliente
Asse dei punti di entrata
Progetti di sviluppo di nuove ideeProgetti di sviluppo di un nuovo prodottoProgetti di miglioramento di un prodottoProgetti di manutenzione di un prodotto
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -92
7/1/03
PianificazioneAnalisi dei rischi
Comunicazioni con il cliente
Strutturazione
Costruzione e rilascio
Valutazione da parte del cliente
Individuazione componenti candidati
Ricerca componenti nella
libreria
Estrazione componenti disponibili
Costruzione componenti non
disponibili
Inserimento nuovi componenti nella
libreria
Costruzione n-esima iterazione
del sistema
Modello ad assemblaggio di componenti
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -93
7/1/03
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 modellingData modelling– process modellingprocess 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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -94
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -95
7/1/03
Riuso o sviluppo ex novo ?
Spesso sono disponibili componenti utili per lo sviluppo: debbono essere utilizzati ?
lavoro da effettuare in creazione o modifica
costo
riuso
Sviluppo ex novo
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -96
7/1/03
Riuso o sviluppo ex novo ?
Riduzione del ciclo di vita del software: come è ripartito fra le varie fasi ?
Maintainance 62%
Testing 15% Analysis 6%
Implementation 7% Design 5%
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -97
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -98
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -99
7/1/03
Lezione 4
Seconda parte: gerarchie
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -100
7/1/03
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
Problema affrontabile
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -101
7/1/03
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 dato per risolto
Problema da affrontare
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -102
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -103
7/1/03
Gerarchie
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
MondoInterfaccia 1
sottosist sottosist
sottosist
Interfaccia 2Interfaccia 1
Interfaccia 3 Interfaccia 4
sottosistGerarchia 3
Gerarchia 2
Gerarchia 2
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -104
7/1/03
Come si definiscono i moduli?
Principio di massima coesione e minimo accoppiamento un modulo deve essere:
internamente massimamente coeso– deve offrire un servizio completodeve offrire un servizio completo
minimamente accoppiato con gli altri moduli – le interfacce devono essere di minima consistenzale interfacce devono essere di minima consistenza– i moduli sono minimamente interdipendentii moduli sono minimamente interdipendenti
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -105
7/1/03
Coesione ed accoppiamento
Spettro della coesioneBassa Alta
“Dispersivo” “Concentrato”
Casuale
Logica
Temporale
Procedurale
Di comunicazione
Sequenziale
Funzionale
Spettro dell’accoppiamentoBassa Alta
Nessun accoppiamento
direttoAccoppiamento di
dati
Accoppiamento a template
Accoppiamento di controllo
Accoppiamentoesterno
Accoppiamento comune
Accoppiamento di contenuto
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -106
7/1/03
Esempio di definizione dei moduli
definire un design corretto e scorretto di modularizzazione
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -107
7/1/03
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à & costo
Maggiore Granularità (+ moduli +piccoli)
Complessità totale
Complessità delle interfacce=
costo di integrazioneComplessità dei modulo
= costo per modulo
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -108
7/1/03
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 140R_auto_1: deve raggiungere la velocità di almeno 140– R _auto_ 2: deve lavorare fra -15° e +45° gradiR _auto_ 2: deve lavorare fra -15° e +45° gradi– R _auto_ 3: deve frenare da 50 km/h a 0km/h in 10 secR _auto_ 3: deve frenare da 50 km/h a 0km/h in 10 sec– R _auto_ 4: deve avere 4 posti comodiR _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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -109
7/1/03
Esempio auto gerarchia primo livello
Motore Mission: muovere la macchina
R_auto_1: deve raggiungere la velocità di almeno 140– R_Moto_1: deve avere 6000 giri con 4KW potenzaR_Moto_1: deve avere 6000 giri con 4KW potenza
R_auto_2: deve lavorare fra -15° e +45°– R_Moto_2: non deve congelare sotto i 15° ...R_Moto_2: non deve congelare sotto i 15° ...
Il motore come sistema è ancora troppo complesso-> espandiamo la gerarchia: motore composto da :
– refrigerazione, refrigerazione, – propulsionepropulsione– centralina di controllocentralina di controllo
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -110
7/1/03
La gerarchia del progetto auto
La struttura è simile ad WBS (work breakdown structure) legami con OBS (organization) e CBS (cost) Quali sono le interfacce ?
esercizio
re frige ra m e n to p ro pu lsio ne co n tro llo
m oto re ru o te fre n i
a cce le ra to re vo lan te
co m a nd i u ten te
friz io ne
ca m b io
a u to
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -111
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -112
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -113
7/1/03
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)
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -114
7/1/03
diagramma funzionale con attori
comanda Auto
guidatore strada
interagisce Gerarchia 1° livello
comandaComandi
auto
strada
interagisce
Gerarchia 2° livello
Motore Ruote freni
guidatore
cambio
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -115
7/1/03
diagramma funzionale: 3° gerarchia
gestisce Motore
Comandi auto
cambio
Invia rotazione Gerarchia 3° livello
strada
interagisce
Ruote
Freni
bloccano
girano
Invia rotazione
Comandi auto cambio
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -116
7/1/03
diagramma funzionale: 4° gerarchia
gestisceMotore
Invia rotazione Gerarchia 3° livello
controllo
propulsore
refrigeramento
Gerarchia 4° livello
cambioComandi
auto
gestisceComandi auto
cambio
Invia rotazione
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -117
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -118
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -119
7/1/03
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 sottosistemarequisiti del sottosistema
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -120
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -121
7/1/03
Lezione 5
Strumenti per l’analisi:
diagrammi E/R, Use case, diagrammi di Eventi
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -122
7/1/03
Mission
Analisi
Design
Implement.
Test
Le fasi della progettazione
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -123
7/1/03
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.
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -124
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -125
7/1/03
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.
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -126
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -127
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -128
7/1/03
Diagrammi E/R (notazione UML)
Oggetto
attributo 1 (ID)
attributo 2..
Oggetto
attributo 1 (ID)
attributo 2..
1..n
CardinalitàRelazione
* Nome relazione
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -129
7/1/03
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
Sistema Gocrcucina
Cameriere
Cliente
Gestore approvvigionamenticassa
Stampa conto
Ordini/ conti
Ordini pietanze
Analisi scorte
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -130
7/1/03
GOCR gerarchia 2° (struttura dati)
Ordine
ID
ID Tavolo
Ora
gestito da
Cameriere
ID
Nome
Quantità richiesta
ID Pietanza
ID ingrediente
quantità
ingrediente
ID
quantità disponibile
Tavolo
ID
stato
Pietanza
ID
tipo
Prezzo
Singolo ord.
ID ordine
id pietanza
quantità
conoscete MS Access ?
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -131
7/1/03
Modello in Access
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -132
7/1/03
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 !!!
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -133
7/1/03
GOCR gerarchia 2° (struttura funzionale)
cucina
Cameriere
Gestore scorte
cassaGestione conti
Gestione ordini
Calcolo contiPreparazione pietanze
Gestione scorte
conti
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -134
7/1/03
Diagramma di stato (stato tavoli) : esercitazione
Convenzione UML
Esercizio: identificare stati
libero,attesa ordine, in_consumazione,richiesta conto identificare transazioni
startstato
transizione
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -135
7/1/03
esercizio: segreteria telefonica
Identificare gli stati e le conessioni
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -136
7/1/03
Use cases: Attori
Clientedi banca
OperatoreBancomat
Sistema informatico
bancario
BANCOMAT
•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.
Studente
Professore
Sistema paghe
Operatore Gestore
Utente sistema
attore
generalizzazione
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -137
7/1/03
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
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -138
7/1/03
Casi d’uso
PrelevamentoCliente della
banca
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.
Gestione Corso
Gestione Piano Corsi Circoscrizione::Richiesta di certificato
semplice nome nome con percorso
SistemaFuori sistema
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -139
7/1/03
Come scrivere un caso d’uso1. 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:
Postcondizioni:
Descrizione:
Eccezioni:
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -140
7/1/03
Descrizione di un caso d’uso
Caso d’uso: Prelevamento contantiQuando 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.
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -141
7/1/03
Caso d’uso: telefonata con il telefonino
l’utente spinge i bottoni del numero di telefono richiesto l’utente aspetta un segnale se libero aspetta ....
...
Caso d’uso
Nome: telefonata con tel
Attori: utente
Precondizioni: acceso
Postcondizioni:
Descrizione:
Eccezioni:
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -142
7/1/03
Professore
Richiesta Corso
Studente
Gestione Piano di Studi
Sistema di tasse
Operatore
Gestione Piano Semestrale
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.
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -143
7/1/03
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à.
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -144
7/1/03
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à
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -145
7/1/03
Diagrammi di sequenze (=di eventi)
Tempo
utente
telefonino
Digita numero
risponde
a
b
c
{b-a<2sec}
Oggetto“Linea della vita”dell’oggetto rappresenta l’esistenza dell’oggetto o dell’attore
Messaggio - call - return - send - create - destroy
{b-a<5sec}
AttivazioneMostra il periodoin cui un oggettorealizza un’azione
etichetta
b
Vincolo
Tempo della transizione
chiamata
Risposta libera
interlocutore
Voce inter.
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -146
7/1/03
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
Sistema Gocrcucina
Cameriere
Cliente
Gestore approvvigionamenticassa
Stampa conto
Ordini/ conti
Ordini pietanze
Analisi scorte
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -147
7/1/03
Esercizio diagramma di sequenza per GOCR
Cameriere
Sistema Gocr
cassacucina
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -148
7/1/03
Esercizio: organizzo una vacanza
IO
amici agenzia Tour operator
Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -149
7/1/03
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