Progettazione di apparati e sistemi di tlc
This presentation is the property of its rightful owner.
Sponsored Links
1 / 149

Progettazione di Apparati e Sistemi di TLC PowerPoint PPT Presentation


  • 87 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Progettazione di Apparati e Sistemi di TLC

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 pennae 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’utente12.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

      • tecnologicideve usare tec.

      • Temporalideve metterci

      • economicideve costare

      • organizzativideve essere organizzato

      • prestazionali

      • relativi all’utilizzodeve 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


    Progettazione di apparati e sistemi di tlc

    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


    Fasi per la creazione di un piano

    Fasi per la creazione di un piano


    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


    Gannt di un video gioco

    Gannt di un video gioco


    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


    Fasi del progetto harvard business school

    Fasi del progetto: Harvard Business School


    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


    Esempio di definizione dei moduli

    definire un design corretto e scorretto di modularizzazione

    Esempio di definizione dei moduli


    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


    Modello in access

    Modello in Access


    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 diagramma di sequenza per gocr

    Cameriere

    cucina

    cassa

    Esercizio diagramma di sequenza per GOCR

    Sistema Gocr


    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


  • Login