progettazione di apparati e sistemi di tlc
Download
Skip this Video
Download Presentation
Progettazione di Apparati e Sistemi di TLC

Loading in 2 Seconds...

play fullscreen
1 / 149

Progettazione di Apparati e Sistemi di TLC - PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on

Progettazione di Apparati e Sistemi di TLC. Laboratorio. Prof. Claudio Becchetti. Lezione 1. Progettazione: “il problema tipico”. Regole del corso. la maggior parte del lavoro si svolge in classe le lezioni sono interattive

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Progettazione di Apparati e Sistemi di TLC' - early


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
progettazione di apparati e sistemi di tlc

Progettazione di Apparati e Sistemi di TLC

Laboratorio

Prof. Claudio Becchetti

lezione 1

Lezione 1

Progettazione: “il problema tipico”

regole del corso
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
metodo di valutazione
metodo di valutazione
  • la valutazione si basa su:
    • voto di gruppo,
    • Voto di coppia (tesina)
    • Esame individuale
  • Tesina: il vostro background ?
preparazione individuale
Preparazione individuale
  • corsi sulla progettazione del software
  • corsi su TLC
  • conoscenze Object oriented
  • conoscenze linguaggi di programmazione
  • Elettronica
  • bioingegneria
  • problem solving ?
testi di riferimento
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)
altri testi
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/
testi opzionali
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).
presentazione del corso
Presentazione del corso
  • Corso di progettazione
    • focus sulla progettazione in generale
      • focus sulla progettazione del software
      • focus sui sistemi di telecomunicazione (TLC)
      • focus su Object Oriented (OO) e C++
  • Perché focus sulla progettazione ?
    • La progettazione è uno strumento per il problem solving
        • esempio paolo
a cosa vi serve veramente questo corso
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)
cosa vede una societ da un neolaureato anche brillante
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
cosa vorrebbe l industria da un neolaureato
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
problem solving e capacit di progettare serve solo nel lavoro
Problem solving e capacità di progettare: serve solo nel lavoro?

Problema risolto

lavoro concluso

Lavoro da fare

Problema da risolvere

Lavoro ben fatto

soluzione adeguata

Vincoli

tempi

costi

risorse

problem solving dove
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
problem solving e progettazione
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
la progettazione e il corso
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 ?
praticone o progettista

Fine task

?

100 %

% Funzionamento

compreso

0 %

Tempo

Praticone o Progettista ?
  • Esempio:
    • Le istruzioni della cinepresa nuova:

Leggete le istruzioni o usate subito la cinepresa ?

task problemi e progettazione

In tempo ?

taskda fare

Concluso ?

Bene ?

Problema da risolvere

Rispetta i vincoli

(costi)?

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

taskda fare

Concluso !!

Problema da risolvere

Tecniche di progettazione

Task problemi e progettazione
esempio
Esempio:
  • Esempio del viaggio
  • la mia organizzazione della settimana bianca
  • e io intanto prenoto (esempio rosanna)
  • “Usa la testa non le gambe”
schema di un problema
Schema di un problema

controlla

Cliente

fornisce

affida

Input

Output

Task

vincoli

Progetta , pianifica, esegue

Le definizioni ?

esecutore

definizioni
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)
definizioni output e test
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à
identificazione di input output e task e test
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 ?
l invariante di input e vincoli
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
esempio1
Esempio

SENIOR PROJECTMANAGER: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.
i dati di input sono esaustivi
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 !!

assunzioni
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
esercizio
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
schema del corso
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
le fasi della progettazione
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)
capacit acquisite nella prima lezione
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
lezione 2

Lezione 2

le fasi della progettazione: la mission, l’analisi

task problemi e progettazione1

In tempo ?

taskda fare

Concluso ?

Bene ?

Problema da risolvere

Rispetta i vincoli?

Lavoro ben fatto

soluzione adeguata

Concluso !!

taskda fare

Problema da risolvere

Tecniche di progettazione

Task problemi e progettazione
perch progettare
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”
perch imparare a progettare
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 ?
non progettare nel software e nelle tlc
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
praticone o progettista1

Fine task

?

100 %

% Funzionamento

compreso

0 %

Tempo

Praticone o Progettista ?
  • Esempio:
    • Le istruzioni della cinepresa nuova:

Leggete le istruzioni o usate subito la cinepresa ?

parte prima le fasi della progettazione
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
le fasi della progettazione1
Le fasi della progettazione

Mission

Analisi

Design

Implement.

Test

1 mission
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

lost the mission fired
Lost the mission-> Fired !
  • Perdere la mission può far licenziare (esempio)
  • la mission deve essere sintetica: le mission nelle aziende
    • IBM

At IBM, we strive to lead in the creation, development and manufacture of the industry\'s most advanced information technologies, including computer systems, software, networking systems, storage devices and microelectronics.

And our worldwide network of IBM solutions and services professionals translates these advanced technologies into business value for our customers

    • Coca cola
      • The Coca-Cola Company exists to benefit and refresh everyone who is touched by our business.
  • Esercizio:
    • trovare alcune mission la Fiat, Xerox, IBM, HP, un teatro
esempi di mission
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 ?
2 analisi
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
i requisiti
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
esempio di requisiti
Esempio di requisiti
  • Le penna:
    • Mission: progettare una penna per scrivere sulla carta
    • Requisiti:
      • La penna dovrà scrivere per almeno un chilometro di carta
      • La penna dovrà avere un costo di produzione inferiore a 1 €
      • La penna dovrà avere una impugnatura giudicata comoda per almeno il 70% degli utilizzatori
      • La penna dovrà scrivere in inchiostro blu o rosso
      • La penna dovrà funzionare fra 0° e i 40°
validazione dei requisiti
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
esempio di requisiti non corretti
Esempio di requisiti non corretti
  • Dash lava più bianco !: come si testa ?
  • Requisiti:
      • La penna dovrà scrivere a lungo
      • La penna dovrà scrivere per almeno un chilometro di carta
      • La penna dovrà costare poco
      • La penna dovrà avere un costo di produzione inferiore a 1 €
      • La penna dovrà avere una impugnatura adeguata
      • La penna dovrà scrivere bene
criteri aggiuntivi di validazione dei requisiti
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
gli errori dell analista
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 ?
gli errori dell analista 2
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
il dominio del problema e della soluzione

sviluppatore

analista

cliente

Il dominio del problema e della soluzione

Dominio del problema

Dominio della soluzione

mission

analisi

design

implementazione

Mondo dellesoluzioni

problema

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

conclusione sugli errori
esercizio ricapitolativo sulla analisi
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
progetto di una festa
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 ?
obiettivi raggiunti
Obiettivi raggiunti
  • dato un problema qualsiasi bisogna essere in grado di:
    • definire la mission (max 3 righe):
    • definire l’analisi:
      • definire i requisiti
        • evitare i requisiti scorretti
        • definire i test dei requisiti
      • evitare gli errori dell’analista:
        • non immettere il design nell’analisi
        • capire il dominio del problema
        • capire il dominio della soluzione
lezione 3

Lezione 3

Design

fallimento dei progetti software
fallimento dei progetti software
  • in che cosa falliscono ?
    • funzioni, tempi e costi previsti
  • quanti progetti falliscono ?
    • 16% successo
    • 53% successo solo parziale
    • 31% fallimento e cancellazione
        • Studio dello Standish Group 1994 su 8380 progetti
  • le percentuali di fallimento sono superiori per progetti di dimensioni maggiori
perch i progetti falliscono
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
tipologie dei requisiti
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
storia di un progetto

Come ha risolto

il problema

la progettazione

Ciò che ha capito

il commerciale

Ciò che ha chiesto

il cliente

Come hanno rimediatoai problemi i responsabili del montaggio

Ciò che realmente voleva il cliente

Ciò che ha realizzato la fabbricazione

Storia di un progetto
il dominio della soluzione il design

sviluppatore

analista

cliente

Il dominio della soluzione: il design

Dominio del problema

Dominio della soluzione

mission

analisi

design

implementazione

Mondo dellesoluzioni

problema

3 design
3: Design

mission

mission

design

  • Dato il “cosa deve fare X” (=analisi)
  • il design specifica come deve essere fatto,
  • il design è il progetto dell’implementazione
    • È come il progetto della casa (costruireste una casa senza il progetto)
  • Il design discende dall’analisi (tracciamento)
    • Per ogni requisito o gruppo di requisiti occorre specificare un insieme di specifiche di realizzazione
  • Attenzione alle incoerenze: (es. la coppia)
esempio di design la penna
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,...
esercizio a squadre sul design
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
validazione del design
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
design iterativo
Design iterativo
  • Il primo design è fondamentale ma è sbagliato !!
    • Il design (specialmente nel sw) va fatto considerando una prima soluzione , migliorandola successivamente

5 design: quasi inutile

3 design: si svolta

100%

6 design: inutile

efficacia

4 design: si migliora poco

2 design

tempo

1 design:

sbagliato ma utile

migliorare il design
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:
esercizio a squadre sul design1
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
implementazione
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
slide70
Test
  • La fase di test serve a verificare se ho raggiunto obiettivi:
  • E’ composta da Verifica e Validazione
    • Verifica :stiamo costruendo un prodotto bene (implementazione soddisfa il design)
      • Si definiscono una serie di test per verificare che il prodotto funziona
    • Validazione :
      • stiamo costruendo il prodotto giusto ?
      • è efficacie ?
      • È quello che ha chiesto il cliente
        • si definiscono una serie di test che discendono dai requisiti e si verificano
        • Verificare che i requisiti di analisi del cliente siano soddisfatti nel prodotto finale
esempio di test
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
esercizi
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
come si gestisce un progetto problema

start

Eseguo

task

fine

pianifico

Quando

finisce ?

monitorizzo

Aggiorno

piani

nuovi

piani

controllo

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
creare il piano del progetto
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
esercitazione sui gannt
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
controllo
Controllo
  • definire le misure per il controllo
  • misurare periodicamente
  • percentuale di lavoro finito
  • la curva di fine
controllo1

100%

controlli

% concluso

tempo

fine

controllo
  • definire le misure di controllo
  • verificare le previsioni con le misure attuali
  • i ritardi: strategie di recovery
  • curve di risposta
problemi della pianificazione controllo
Problemi della pianificazione/controllo
  • pianificazione
    • valutazione delle prestazioni della risorsa
    • disponibilità risorse
    • percorso critico
    • compatibilità con le scadenze
    • priorità
    • vincoli
    • forward scheduling backward scheduling
verificare i ritardi
Verificare i ritardi

Fine reale

previsione

100%

controlli

% concluso

Misura reale

Fine

teorica

oggi

esercitazioni
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
obiettivi raggiunti1
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
lezione 4

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

modelli del processo software
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
modello a cascata grand design
Modello “a cascata”: Grand design

Il software è una parte di un sistema più ampio. Sono necessarie un’analisi e una progettazione di alto livello per raccogliere tutti i requisiti, da cui il software utilizza solo una parte.

Strutturazione e modellazione del sistema e dei dati (livello sistema)

Analisi dei requisiti sw.

Progettazione

Codifica

Collaudo

strutture di dati, architettura del software, interfacce, algoritmi delle operazioni

codice

dominio delle informazioni, funzionalità, comportamento, prestazioni, interfacce

  • 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
sviluppo evolutivo
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

sviluppo evolutivo del software
Sviluppo evolutivo del software

Specificare l’incremento del sistema

Costruire l’incremento del sistema

Collaudare l’incremento del sistema

Definire l’output del sistema

Rilasciare l’incremento del sistema

Sistema è completo?

Completare il rilascio del sistema

1. Non c’è tempo per una versione completa però dobbiamo uscire sul mercato.

2. Esiste un nucleo di requisiti di sistema ma i dettagli delle estensioni non esistono ancora.

Soluzione: modello di processo per un prodotto che evolve nel tempo

modello incrementale
Modello incrementale

Utile quando la disponibilità del personale è insufficiente a garantire l’implementazione completa. Si comincia con un piccolo team. Il team accresce se l’accoglienza è positiva.

Strutturazione del sistema

e dei dati

Stadio 1

Proget tazione

Consegna dello stadio 1

Analisi

Codifica

Collaudo

Implementa solo

una parte dei requisiti

Proget tazione

Consegna dello stadio 2

Stadio 2

Analisi

Codifica

Collaudo

Proget tazione

Consegna dello stadio 3

Stadio 3

Analisi

Codifica

Collaudo

Si partizionano i requisiti in tre stadi a seconda delle priorità

modello a spirale
Modello a spirale

Comunicazioni con il cliente

Pianificazione

Asse dei punti di entrata

Analisi dei rischi

Valutazione da parte del cliente

Strutturazione

Costruzione e rilascio

Sei attività portanti

(task region):

Progetti di sviluppo di nuove idee

Progetti di sviluppo di un nuovo prodotto

Progetti di miglioramento di un prodotto

Progetti di manutenzione di un prodotto

Il modello abbina la natura iterativa della prototipazione e gli aspetti controllati e sistematici del modello sequenziale.

modello ad assemblaggio di componenti
Modello ad assemblaggio di componenti

Analisi dei rischi

Pianificazione

Individuazione componenti candidati

Comunicazioni con il cliente

Costruzione

n-esima iterazione del sistema

Ricerca componenti nella libreria

Inserimento nuovi componenti nella libreria

Estrazione componenti disponibili

Valutazione da parte del cliente

Strutturazione

Costruzione e rilascio

Costruzione componenti non disponibili

modello di sviluppo rad
modello di sviluppo RAD

consentono un tempo di sviluppo molto ridotto

il modello di sviluppo è :

analisi

Business modelling: definizione dei flussi informativi e dei processi

Data modelling

process modelling

design / implementation

application generation: direttamente con il tool di 4g. Molto del codice è già implementato nel tool

testing

limitato perchè la maggior parte del software è già sviluppato

pro contro del modello rad
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

riuso o sviluppo ex novo
Riuso o sviluppo ex novo ?

Spesso sono disponibili componenti utili per lo sviluppo: debbono essere utilizzati ?

Sviluppo ex novo

costo

riuso

lavoro da effettuare in creazione o modifica

riuso o sviluppo ex novo1
Riuso o sviluppo ex novo ?
  • Riduzione del ciclo di vita del software: come è ripartito fra le varie fasi ?
analisi del costo di sviluppo
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
quale modello
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
lezione 41

Lezione 4

Seconda parte: gerarchie

regola fondamentale divide et impera
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

implicazioni del divide et impera
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

dal sistema al dettaglio gerarchie e zoom
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
gerarchie
Gerarchie

Gerarchia 2

Mondo

Interfaccia 1

  • Dato un sistema connesso con l’esterno da interfacce esterne, una gerarchia è composta da:
    • sottosistemi che partizionano il sistema
    • interfacce che connettono i sottosistemi
    • le interfacce esterne che connettono i sottosistemi con il mondo esterno

sistema

Interfaccia 2

Interfaccia 1

sottosist

sottosist

Interfaccia 3

Interfaccia 4

sottosist

Gerarchia 2

Gerarchia 3

sottosist

come si definiscono i moduli
Come si definiscono i moduli?
  • Principio di massima coesione e minimo accoppiamento
    • un modulo deve essere:
      • internamente massimamente coeso
        • deve offrire un servizio completo
      • minimamente accoppiato con gli altri moduli
        • le interfacce devono essere di minima consistenza
        • i moduli sono minimamente interdipendenti
coesione ed accoppiamento

Casuale

Temporale

Di comunicazione

Funzionale

Logica

Procedurale

Sequenziale

Bassa

Spettro della coesione

Alta

“Dispersivo”

“Concentrato”

Nessun accoppiamento diretto

Accoppiamento a template

Accoppiamento

esterno

Accoppiamento di contenuto

Accoppiamento di dati

Accoppiamento di controllo

Accoppiamento comune

Bassa

Spettro dell’accoppiamento

Alta

Coesione ed accoppiamento
determinazione del numero dei moduli
Determinazione del numero dei moduli
  • Quanti moduli devo fare
    • il costo di un sistema è proporzionale alla complessità
    • la complessità è data dalla somma della complessità intramodulo e della complessità delle interfacce intermoduli

Complessità

totale

Complessità &

costo

Complessità

delle interfacce=

costo di integrazione

Complessità

dei modulo

= costo per modulo

Maggiore Granularità (+ moduli +piccoli)

esempio progettazione di una auto
Esempio: progettazione di una auto
  • auto troppo complessa!Divide et impera !
    • Definisco la mission
      • progettare una auto utilitaria per l’Italia
    • Definisco analisi del sistema auto
        • R_auto_1: deve raggiungere la velocità di almeno 140
        • R _auto_ 2: deve lavorare fra -15° e +45° gradi
        • R _auto_ 3: deve frenare da 50 km/h a 0km/h in 10 sec
        • R _auto_ 4: deve avere 4 posti comodi
    • definisco i sottosistemi (gerarchia di primo livello)
      • motore, carrozzeria, ruote,freni, volante, cambio
    • definisco le interfacce fra i sottosistemi
esempio auto gerarchia primo livello
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 potenza
      • R_auto_2: deve lavorare fra -15° e +45°
        • R_Moto_2: non deve congelare sotto i 15° ...
  • Il motore come sistema è ancora troppo complesso-> espandiamo la gerarchia:
    • motore composto da :
        • refrigerazione,
        • propulsione
        • centralina di controllo
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

La gerarchia del progetto auto
regole per la costruzione della gerarchia
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
coerenza delle gerarchie per le interfacce
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
gli attori
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)
diagramma funzionale con attori

interagisce

comanda

comanda

interagisce

guidatore

guidatore

strada

strada

diagramma funzionale con attori

Gerarchia

1° livello

Auto

Comandi auto

Gerarchia

2° livello

freni

Ruote

Motore

cambio

diagramma funzionale 3 gerarchia

Invia rotazione

gestisce

interagisce

Comandi auto

Comandi auto

cambio

cambio

strada

Freni

diagramma funzionale: 3° gerarchia

Gerarchia

3° livello

Motore

girano

Ruote

bloccano

Invia rotazione

diagramma funzionale 4 gerarchia

Invia rotazione

Invia rotazione

gestisce

gestisce

Comandi auto

Comandi auto

cambio

cambio

diagramma funzionale: 4° gerarchia

Gerarchia

3° livello

Motore

Gerarchia

4° livello

controllo

propulsore

refrigeramento

requisiti di interfaccia
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
esercizio il ristorante
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
esercitazione sistema gestione ordini e conto per ristoranti
Esercitazione: sistema gestione ordini e conto per ristoranti
  • mission: progettare un sistema informatico che gestisca gli ordini e il conto finale per ogni ristorante
    • analisi di sistema
      • requisiti del sistema
      • attori
      • interfacce esterne e requisiti associati
    • definire i sottosistemi (gerarchia di primo ordine)
      • definire interfacce interne fra sottosistemi e requisiti associati
      • associare interfacce esterne a sottosistemi
      • analisi di sottosistema
        • requisiti del sottosistema
obiettivi raggiunti2
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
lezione 5

Lezione 5

Strumenti per l’analisi:

diagrammi E/R, Use case, diagrammi di Eventi

le fasi della progettazione2
Le fasi della progettazione

Mission

Analisi

Design

Implement.

Test

attivit di analisi
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.
attivit di analisi 1
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
attivit di analisi 2
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.
strumenti di analisi
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
modello dei dati
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
diagrammi e r notazione uml

Oggetto

attributo 1 (ID)

attributo 2..

Oggetto

attributo 1 (ID)

attributo 2..

Cardinalità

Relazione

Diagrammi E/R (notazione UML)

Nome relazione

*

1..n

sistema gestione ordini e conto per ristoranti gocr gerarchia 1

Cliente

Gestore approvvigionamenti

Cameriere

cucina

cassa

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

Ordini/ conti

Sistema Gocr

Ordini pietanze

Stampa conto

Analisi scorte

gocr gerarchia 2 struttura dati
conoscete MS Access ?

ingrediente

ID

quantità disponibile

Quantità richiesta

ID Pietanza

ID ingrediente

quantità

Pietanza

ID

tipo

Prezzo

Singolo ord.

ID ordine

id pietanza

quantità

Cameriere

ID

Nome

Tavolo

ID

stato

GOCR gerarchia 2° (struttura dati)

Ordine

ID

ID Tavolo

Ora

gestito da

diagrammi e r
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 !!!
gocr gerarchia 2 struttura funzionale

Gestore scorte

Cameriere

cucina

cassa

GOCR gerarchia 2° (struttura funzionale)

conti

Gestione conti

Preparazione pietanze

Calcolo conti

Gestione ordini

Gestione scorte

diagramma di stato stato tavoli esercitazione

start

transizione

stato

Diagramma di stato (stato tavoli) : esercitazione
  • Convenzione UML
  • Esercizio:
    • identificare stati
      • libero,attesa ordine, in_consumazione,richiesta conto
    • identificare transazioni
esercizio segreteria telefonica
esercizio: segreteria telefonica
  • Identificare gli stati e le conessioni
use cases attori

Cliente

di banca

Utente sistema

Operatore

Gestore

BANCOMAT

Professore

Studente

Sistema paghe

Sistema

informatico

bancario

Operatore

Bancomat

Use cases: Attori
  • Qualunque entità esterna interagisce con il sistema, persone o macchine, può essere modellizzato come un attore.
  • Analizzando gli attori ci concentriamo su come il sistema sarà utilizzato e non su come sarà progettato o implementato.

attore

generalizzazione

casi d uso use cases
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
casi d uso

semplice nome

nome con percorso

Gestione Corso

Circoscrizione::Richiesta di certificato

Prelevamento

Cliente della

banca

Gestione Piano Corsi

Casi d’uso
  • Casi d’uso e attori:
  • Ciascun caso d’uso può coinvolgere più attori.
  • Un attore può utilizzare più casi d’uso dello stesso sistema.
  • Per ciascun attore, si deve identificare come vuole utilizzare il sistema. Ciascun modo di utilizzare il sistema diventa un caso d’uso.

Fuori sistema

Sistema

come scrivere un caso d uso

Caso d’uso

Nome:

Attori:

Precondizioni:

Descrizione:

Eccezioni:

Postcondizioni:

Come scrivere un caso d’uso

1. Viene creato un documento di flusso di eventi per ciascun caso d’uso. Il documento è scritto dal punto di vista di un attore.

2. Viene dettagliato che cosa il sistema deve rilasciare all’attore quando il caso d’uso viene eseguito.

Tipicamente il documento contiene:

  • Come inizia e come si termina il caso d’uso
  • Il flusso normale di eventi
  • I flussi alternativi di eventi
  • I flussi straordinari di eventi
descrizione di un caso d uso
Descrizione di un caso d’uso

Caso d’uso: Prelevamento contanti

Quando un cliente inserisce la carta, la macchina legge il codice della carta e verifica se si tratta di una carta valida. Se non è valida, viene espulsa. Altrimenti si richiede il codice PIN (5 cifre) al utente.

Quando il codice PIN è stato inserito, la macchina verifica se il codice è corretto per la carta utilizzata. In caso positivo, la macchina richiede che tipo di transazione si desidera eseguire.

Quando il cliente seleziona Prelevamento contanti la macchina richiede la somma. Sono permessi soltanto multipli di Lit. 50.000.

Quando ….

Un caso d’uso descrive un insieme di sequenze di eventi che sono varianti nello stesso caso. Ciascuna sequenza rappresenta uno scenario. Uno scenario è rispetto ad un caso d’uso come un‘istanza rispetto alla classe.

caso d uso telefonata con il telefonino

Caso d’uso

Nome: telefonata con tel

Attori: utente

Precondizioni: acceso

Descrizione:

Eccezioni:

Postcondizioni:

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

...

diagrammi di casi d uso

Richiesta Corso

Professore

Studente

Gestione Piano di Studi

Sistema di tasse

Gestione Piano Semestrale

Operatore

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.

identificazione dei casi d uso
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à.

diagramma di eventi
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à
diagrammi di sequenze di eventi

“Linea della vita”

dell’oggetto

rappresenta

l’esistenza

dell’oggetto o

dell’attore

Oggetto

Attivazione

Mostra il periodo

in cui un oggetto

realizza un’azione

Messaggio

- call

- return

- send

- create

- destroy

etichetta

Vincolo

{b-a<5sec}

Tempo della

transizione

b

Diagrammi di sequenze (=di eventi)

telefonino

utente

interlocutore

Digita numero

a

chiamata

Risposta libera

{b-a<2sec}

risponde

b

Voce inter.

c

Tempo

sistema gestione ordini e conto

Cliente

Gestore approvvigionamenti

Cameriere

cucina

cassa

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

Ordini/ conti

Sistema Gocr

Ordini pietanze

Stampa conto

Analisi scorte

esercizio organizzo una vacanza

IO

Esercizio: organizzo una vacanza

Tour operator

agenzia

amici

obiettivi raggiunti3
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
ad