Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza 7/1/03 Progettazione di Apparati...

Copyright Prof. Claudio Becchetti, Università di Roma “La Sapienza” -1

7/1/03

Progettazione di Apparati e Sistemi di TLC

Prof. Claudio Becchetti

Laboratorio


7/1/03

Lezione 1

Progettazione: “il problema tipico”


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


7/1/03

metodo di valutazione

la valutazione si basa su: voto di gruppo, Voto di coppia (tesina) Esame individuale

Tesina: il vostro background ?


7/1/03

Preparazione individuale

corsi sulla progettazione del software corsi su TLC conoscenze Object oriented conoscenze linguaggi di programmazione Elettronica bioingegneria problem solving ?


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)


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/


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).


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


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)


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


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


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


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


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


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 ?


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?


7/1/03

Task problemi e progettazionetask

da fare


Concluso ?

In tempo ?

Bene ?

Rispetta i vincoli(costi)?

•Tempi rispettati•costi rispettati•funzioni coperte con adeguata qualità

Concluso !!

taskda fare


Tecniche di progettazioneTecniche di progettazione


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”


7/1/03

Schema di un problema

Cliente

InputInput OutputTask

fornisce

controlla

Progetta , pianifica, esegue

affida

vincoli

esecutore

Le definizioni ?


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)


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à


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 ?


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


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.


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 !!


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


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


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


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)


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


7/1/03

Lezione 2

le fasi della progettazione: la mission, l’analisi


7/1/03

Task problemi e progettazionetask

da fare


Concluso ?

In tempo ?

Bene ?

Rispetta i vincoli?

Lavoro ben fattosoluzione adeguata

Concluso !!

taskda fare


Tecniche di progettazioneTecniche di progettazione


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”


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%


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


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?


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


7/1/03

Le fasi della progettazione

Mission

Analisi

Design

Implement.

Test


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


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


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 ?


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


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


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°


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


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


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


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 ?


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


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


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


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


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 ?


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


7/1/03

Lezione 3

Design


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


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


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


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


7/1/03

Il dominio della soluzione: il design

mission analisi design implementazione

Dominio della soluzioneDominio del problema

cliente

analista

problema

sviluppatore

Mondo dellesoluzioni


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


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,...


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


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


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%


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:


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


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


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


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


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


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


7/1/03

Fasi per la creazione di un piano


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


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


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


7/1/03

Controllo

definire le misure per il controllo misurare periodicamente percentuale di lavoro finito la curva di fine


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


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


7/1/03

Verificare i ritardi

oggi

% concluso

100%

Fine teorica

controlli

previsione

Misura reale

Fine reale


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


7/1/03

Fasi del progetto: Harvard Business School


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


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


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


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


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


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


7/1/03

Strutturazione del sistemae dei dati

AnalisiProget tazione

Codifica Collaudo

Stadio 1

Consegna dello stadio 1


Codifica CollaudoStadio 2 Consegna dello stadio 2


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à


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


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


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


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


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


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%


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


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


7/1/03

Lezione 4

Seconda parte: gerarchie


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


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


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


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


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


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


7/1/03

Esempio di definizione dei moduli

definire un design corretto e scorretto di modularizzazione


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


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


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


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


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


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


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)


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


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


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


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


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


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


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


7/1/03

Lezione 5

Strumenti per l’analisi:

diagrammi E/R, Use case, diagrammi di Eventi


7/1/03

Mission

Analisi

Design

Implement.

Test

Le fasi della progettazione


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.


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


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.


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


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


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


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


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 ?


7/1/03

Modello in Access


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 !!!


7/1/03

GOCR gerarchia 2° (struttura funzionale)

cucina

Cameriere

Gestore scorte

cassaGestione conti

Gestione ordini

Calcolo contiPreparazione pietanze

Gestione scorte

conti


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


7/1/03

esercizio: segreteria telefonica

Identificare gli stati e le conessioni


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


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


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


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:


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.


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:


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.


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à.


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à


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.


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


7/1/03

Esercizio diagramma di sequenza per GOCR

Cameriere

Sistema Gocr

cassacucina


7/1/03

Esercizio: organizzo una vacanza

IO

amici agenzia Tour operator


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

Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza 7/1/03 Progettazione di Apparati...

Documents

Transcript of Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza 7/1/03 Progettazione di Apparati...