Progettazione di Apparati e Sistemi di TLC

Presentazione sul tema: "Progettazione di Apparati e Sistemi di TLC"— Transcript della presentazione:

1 Progettazione di Apparati e Sistemi di TLC
Laboratorio Prof. Claudio Becchetti 7/1/03

2 Progettazione: “il problema tipico”
Lezione 1 Progettazione: “il problema tipico” 7/1/03

3 Regole del corso la maggior parte del lavoro si svolge in classe
le lezioni sono interattive Colui che chiede una domanda può diventare uno stupido per 5 minuti, colui che non la chiede sarà uno stupido per sempre (prov. cinese) Creare il cartellino badge la valutazione finale non si basa sulle risposte date in classe 7/1/03

4 metodo di valutazione la valutazione si basa su:
voto di gruppo, Voto di coppia (tesina) Esame individuale Tesina: il vostro background ? 7/1/03

5 Preparazione individuale
corsi sulla progettazione del software corsi su TLC conoscenze Object oriented conoscenze linguaggi di programmazione Elettronica bioingegneria problem solving ? 7/1/03

6 Testi di riferimento TLC Software
Reti di Computer,Tanenbaum A. , Prentice Hall Int (anche in italiano) Digital Communications, Proakis J. G., McGraw-Hill Software Software Engineering, Pressmann Roger S. , McGraw-Hill, (anche in italiano) UML Distilled: Applying the Standard Object Modeling Language, Martin Fowler, Kendall Scott, Addison-Wesley (anche in italiano) 7/1/03

7 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 Jézéquel J.M., Meyer B., “Design by contract: the lesson of Ariane”, IEEE Computer, 30, No. 2, pp (Jan. 1997) also available in 7/1/03

8 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 Object-Oriented Programming, Cantù M., Tendon S., Random House/Borland Press (1995) Cline M. P., Lomow G. A., C++ Faqs, Addison Wesley (1995). 7/1/03

9 Presentazione del corso
Corso di progettazione focus sulla progettazione in generale focus sulla progettazione del software focus sui sistemi di telecomunicazione (TLC) focus su Object Oriented (OO) e C++ Perché focus sulla progettazione ? La progettazione è uno strumento per il problem solving esempio paolo 7/1/03

10 a cosa vi serve veramente questo corso ?
Non progetterete mai ? Non svilupperete mai il sw ? non vi occuperete mai di TLC ? Il C++ sarà superato l’object oriented non serve ? Dopo un mese dall’esame vi sarete dimenticati tutte le nozioni apprese ? Il corso è indirizzato alla progettazione secondo le esigenze del mondo del lavoro progettare significa risolvere i problemi (problem solving) 7/1/03

11 cosa vede una società da un neolaureato anche brillante
un elemento grezzo da formare a seconda dei lavori occorrono nell’ordine dei 12 mesi perché un neolaureato sia “operativo” nei primi 12 mesi il neolaureato non è in grado di fare quasi nulla per l’industria per rendere operativo un neolaureato, occorre molto addestramento (“training on the job” ) l’organizzazione cerca di insegnare il problem solving nella fase di addestramento 7/1/03

12 cosa vorrebbe l’industria da un neolaureato
capacità di analizzare e risolvere problemi/lavori complessi e nuovi capacità di rispettare i vincoli del problema (tempi, costi e risorse disponibili) capacità di rispettare i vincoli per risolvere il problema (tempi costi e risorse disponibili) a prescindere dal settore di impiego (software, tlc, gestionale, marketing, ...) Quindi -> problem solving: capacità di portare a termine con profitto un lavoro in maniera autonoma 7/1/03

13 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 7/1/03

14 Problem solving: dove ? creare un sistema tlc organizzare una vacanza Aprire un ristorante produrre un software creare un nuovo prodotto organizzare una festa lasciare la ragazza? Il problem solving serve ovunque si presenti un problema/ lavoro: 1) importante 2) di complessità non banale 7/1/03

15 Problem solving e progettazione
Ogni volta che dobbiamo risolvere un problema o fare un lavoro importante occorre: progettare il lavoro/ la soluzione Progettare significa stabilire: cosa bisogna fare Come implementarlo In che tempi Con che risorse Come verificare cosa si è implementato la capacità di problem solving si acquisisce imparando a progettare 7/1/03

16 La progettazione e il corso
lo scopo del corso è di insegnare a progettare vi verranno insegnate nel corso le tecniche di progettazione che dovrete applicare a casi concreti le tecniche di progettazione servono solo nel mondo del lavoro ? le tecniche di progettazione servono solo nel campo del software TLC ? 7/1/03

17 Praticone o Progettista ?
Esempio: Le istruzioni della cinepresa nuova: Leggete le istruzioni o usate subito la cinepresa ? Tempo % Funzionamento compreso 0 % 100 % Fine task ? 7/1/03

18 Task problemi e progettazione
task da fare Problema da risolvere Concluso ? In tempo ? Bene ? Rispetta i vincoli (costi)? Tempi rispettati costi rispettati funzioni coperte con adeguata qualità Concluso !! task da fare Problema da risolvere Tecniche di progettazione 7/1/03

19 “Usa la testa non le gambe”
Esempio: Esempio del viaggio la mia organizzazione della settimana bianca e io intanto prenoto (esempio rosanna) “Usa la testa non le gambe” 7/1/03

20 Progetta , pianifica, esegue
Schema di un problema controlla Cliente fornisce affida Input Output Task vincoli Progetta , pianifica, esegue Le definizioni ? esecutore 7/1/03

21 Definizioni Task Input Vincoli
tutto le operazioni che devo compiere per ottenere l’output Input tutto ciò che posso o devo prendere dall’ambiente esterno per portare a termine il task, informazioni (dati, scadenze, costi, tempi) risorse (mezzi fisici, persone, soldi) Vincoli possono impedire la soluzione del task (vincoli incrociati) 7/1/03

22 Definizioni (output e test)
il risultato del mio lavoro: informazioni , servizi, mezzi trasformati , documenti, progetti, software ... Test metodi implementati da me o dal mondo esterno per verificare che l’output sia adeguato Cliente chi mi chiede di: risolvere un problema definire delle soluzioni portare a termine una attività 7/1/03

23 identificazione di input output e task e test
Esercitazione creare una tabella a 5 colonne : nome del task come di seguito, input , vincoli, descrizione task, output, test) creazione video gioco software lavoro di gruppo progettazione di un telefonino produzione di un telefonino organizzazione di un concerto organizzazione di una vacanza con un gruppo di amici quale è la differenza fra input e vincolo ? 7/1/03

24 L’Invariante di Input e vincoli
tutti i problemi implicano tempi di realizzazione (cioè pianificazione controllo) costi (budget a disposizione) risorse (umane, materiali) per affrontare un problema/ progettazione occorre definire sempre chiaramente i tre aspetti 7/1/03

25 Esempio SENIOR PROJECT MANAGER:Descrizione E' responsabile della stesura, sviluppo e gestione di progetti informatici incentrati sulle applicazioni di Rete per l'interazione Internet, Intranet ed Extranet. In particolare il suo ruolo prevede: la definizione, con il cliente, del piano di lavoro e delle modalità di collaborazione nell'ambito di system integration; l'analisi e la valutazione delle diverse componenti del progetto (costi, tempi e risorse); la gestione del team interno di lavoro e degli eventuali partner; la verifica dei risultati raggiunti. 7/1/03

26 I dati di input sono esaustivi ?
Se il problema non è banale, i dati di input non sono mai sufficienti per avere un task univoco e una soluzione univoca. Questo è la causa più frequente di incapacità di portare a termine un task soprattutto in problemi mai affrontati altra causa di paralisi nel portare a termine un task sono i vincoli incrociati Come si procede ? Le assunzioni !! 7/1/03

27 Assunzioni L’assunzione deve essere: Le assunzioni servono a
plausibile nel contesto del task esplicitata (deve essere menzionata da qualche parte) Le assunzioni sono spesso collegate ai soldi e sono fondamentali per la buona riuscita di un progetto (ref. il registro delle assunzioni) Le assunzioni servono a Ridurre il numero di possibilità di design Semplificare Limitare e vincolare il task (l’oggetto non farà questo) Definire delle preferenze (p.es. linguaggio usato) eliminare i vincoli 7/1/03

28 Esercizio: progettazione di un telefonino produzione di un telefonino
identificare le assunzioni dei precedenti casi creazione video gioco software progettazione di un telefonino produzione di un telefonino organizzazione di un concerto organizzazione di una vacanza con un gruppo di amici nel corso vi sono volutamente (come nella realtà) case study con dati di input incompleti o vincoli incrociati E’ fondamentale che voi identifichiate e tracciate le assunzioni per evitare input incompleti o vincoli incrociati E’ compito del committente accettare le assunzioni 7/1/03

29 Schema del corso parte 1 ; le fasi della progettazione
parte 2 : la progettazione strutturata parte 3: la progettazione a oggetti e classi parte 4: la progettazione object oriented 7/1/03

30 le fasi della progettazione
Progettare “X” significa stabilire: 1: Mission (cosa è “X” e purché faccio “X” ) 2: Analisi (cosa fa “X” ) 3: Design (come realizzo “X” ) 4: Implementazione (“X” realizzato) 5: Test (“X realizzato funziona ? È adeguato ?” : Rispetta design (è come lo volevo implementare) Rispetta analisi (fa ciò che avevo progettato di fargli fare) Rispetta la mission (soddisfa il motivo per cui lo avevo fatto) 7/1/03

31 Capacità acquisite nella prima lezione
dato un problema qualsiasi: identificare input vincoli output task cliente test individuare input incompleti/vincoli incrociati definire assunzioni plausibili individuare i rischi 7/1/03

32 le fasi della progettazione: la mission, l’analisi
Lezione 2 le fasi della progettazione: la mission, l’analisi 7/1/03

33 Task problemi e progettazione
task da fare Problema da risolvere Concluso ? In tempo ? Bene ? Rispetta i vincoli? Lavoro ben fatto soluzione adeguata Concluso !! task da fare Problema da risolvere Tecniche di progettazione 7/1/03

34 Perché progettare ? Progettare è frustrante progettare è vincente
All’inizio si raggiungono risultati più lentamente È una attività impegnativa perché richiede forte uso di attività concettuale invece si tende a prediligere attività celebrale “manuale” Stanca più velocemente progettare è vincente Garantisce il risultato giusto in tempi certi Il tempo impiegato è molto inferiore rispetto all’approccio da “code and fix”. “Usa la testa e non le gambe” 7/1/03

35 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 ? 7/1/03

36 Non progettare nel software e nelle TLC
Non progettare significa: I tempi per concludere un task possono dilatarsi all’infinito (comune nella codifica del software) Non si sa mai quando si finisce (per fare il 5% del lavoro occorre il 95 % del tempo ?) La qualità del prodotto è bassa, richiede normalmente rilavorazioni per correggere errori Il prodotto può essere gestito solo da chi lo ha creato 7/1/03

37 Praticone o Progettista ?
Esempio: Le istruzioni della cinepresa nuova: Leggete le istruzioni o usate subito la cinepresa ? Tempo % Funzionamento compreso 0 % 100 % Fine task ? 7/1/03

38 Parte prima: le fasi della progettazione
Progettare “X” significa stabilire: 1: Mission (cosa è “X” e purché faccio “X” ) 2: Analisi (cosa fa “X” ) 3: Design (come realizzo “X” ) 4: Implementazione (“X” realizzato) 5: Test (“X realizzato funziona ? È adeguato ?” : Rispetta design (è come lo volevo implementare) Rispetta analisi (fa ciò che avevo progettato di fargli fare) Rispetta la mission (soddisfa il motivo per cui lo avevo fatto) Case study: la penna 7/1/03

39 Le fasi della progettazione
Mission Analisi Design Implement. Test 7/1/03

40 1: Mission è difficile da individuare è difficile da seguire
Indica la meta, la direzione e lo scopo del task che si vuole compiere È espresso in forma concisa (max 3 righe) Serve a eliminare i problemi di framework Esempio di framework (es. la Russia in sede) E’ un “contratto” con il cliente: Va concordato con il cliente È focalizzato sui bisogni del cliente è difficile da individuare è difficile da seguire 7/1/03

41 Lost the mission-> Fired !
Perdere la mission può far licenziare (esempio) la mission deve essere sintetica: le mission nelle aziende IBM At IBM, we strive to lead in the creation, development and manufacture of the industry's most advanced information technologies, including computer systems, software, networking systems, storage devices and microelectronics. And our worldwide network of IBM solutions and services professionals translates these advanced technologies into business value for our customers Coca cola The Coca-Cola Company exists to benefit and refresh everyone who is touched by our business. Esercizio: trovare alcune mission la Fiat, Xerox, IBM, HP, un teatro 7/1/03

42 Esempi di mission Quali assunzioni ? Esercizio definire la mission per
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. 7/1/03

43 2: Analisi Specifica che cosa deve fare il prodotto/servizio indicato nella mission Deve discendere ed essere coerente con la mission Esempio di incoerenza fra mission e analisi (la coppia faffi) E’ una lista di requisiti secondo il punto di vista del cliente utilizzatore se non si è capaci di fare analisi non si è capaci di codificare il software 7/1/03

44 I requisiti I requisiti sono un qualcosa desiderato dal cliente espresso in forma di frase testuale I requisiti dovrebbero essere numerati I requisiti dovrebbero essere testabili I requisiti dovrebbero essere univoci,non sovrapponibili, non ambigui I requisiti dovrebbero coprire completamente i desiderata del cliente i requisiti sono definiti dall’analista in base alle richieste del cliente, o sono direttamente forniti dal cliente 7/1/03

45 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° 7/1/03

46 Validazione dei requisiti
Il cliente dà spesso requisiti ambigui/incompleti l’analista li trasforma in modo che i requisiti siano: numerati testabili Definire un test per i precedenti requisiti Non sovrapposti Coprano completamente i desiderata del cliente 7/1/03

47 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 7/1/03

48 Criteri aggiuntivi di validazione dei requisiti
Fattibilità Siamo in grado di farlo ? Abbiamo il tempo i soldi le capacità le persone giuste (il caso ATC USA) Accettabilità Ci conviene farlo ? Otteniamo qualcosa di soddisfacente come performance Vulnerabilità qualsiasi cosa che può andare male andrà male (Murphy) Quali sono i rischi / conseguenze delle nostre scelte ? Essendo pessimisti cosa può andar male e se va male quali sono le conseguenze 7/1/03

49 Gli errori dell’analista
Esempio di errore esempio della penna e del software () Errore tipico e grave: inserire nell’analisi di X come va fatto X (=design) quali sono le implicazioni di questo errore ? L’errore ha impatto su costi tempi e risorse ? 7/1/03

50 Gli errori dell’analista 2
esempio: una società di consulenza invia un ingegnere neolaureato ad un corso approfondito di analisi UML l’ingegnere fa grande esperienza di analisi la società di consulenza deve effettuare un lavoro di informatizzazione presso una azienda e decide di inviare l’ingegnere per il lavoro di analisi quali sono i problemi che incontrerà l’ingegnere ? 1:esempio 2:esempio 7/1/03

51 Il dominio del problema e della soluzione
Dominio della soluzione mission analisi design implementazione Mondo delle soluzioni problema analista sviluppatore cliente 7/1/03

52 conclusione sugli errori
l’analista non deve confondere analisi con design l’analista deve conoscere il dominio del problema l’analista deve conoscere il dominio della soluzione 7/1/03

53 Esercizio ricapitolativo sulla analisi
Definire mission e analisi per i seguenti problemi, per ogni requisito definire un test Uno scanner Una videocamera Un telefonino Una radio Un programma di posta elettronica Un ristorante Una festa 7/1/03

54 Progetto di una festa Il committente richiede un festa
L’organizzatore chiede come organizzarla Il committente risponde: l’importante è che ci divertiamo Requisito: divertirsi ? Testabile ? (il cliente mi paga se si è divertito ?) Cosa fa l’organizzatore ? 7/1/03

55 Obiettivi raggiunti dato un problema qualsiasi bisogna essere in grado di: definire la mission (max 3 righe): definire l’analisi: definire i requisiti evitare i requisiti scorretti definire i test dei requisiti evitare gli errori dell’analista: non immettere il design nell’analisi capire il dominio del problema capire il dominio della soluzione 7/1/03

56 Lezione 3 Design 7/1/03

57 fallimento dei progetti software
in che cosa falliscono ? funzioni, tempi e costi previsti quanti progetti falliscono ? 16% successo 53% successo solo parziale 31% fallimento e cancellazione Studio dello Standish Group 1994 su 8380 progetti le percentuali di fallimento sono superiori per progetti di dimensioni maggiori 7/1/03

58 Perché i progetti falliscono
1: Requisiti incompleti % 2: mancato coinvolgimento dell’utente 12.4% 3: Mancanza di risorse % 4: Attese irrealistiche % 5: mancanza di supporti della direzione % 6: cambio di requisiti % 7: mancanza di pianificazione % 8: non serve più % A quali fasi riconducete i fallimenti 7/1/03

59 tipologie dei requisiti
tipologie di requisiti funzionali deve fare tecnologici deve usare tec. Temporali deve metterci economici deve costare organizzativi deve essere organizzato prestazionali relativi all’utilizzo deve essere usato alla sicurezza 7/1/03

60 Storia di un progetto Ciò che ha chiesto Ciò che ha capito il cliente
Come ha risolto il problema la progettazione Ciò che ha capito il commerciale Ciò che ha realizzato la fabbricazione Ciò che realmente voleva il cliente Come hanno rimediato ai problemi i responsabili del montaggio 7/1/03

61 Il dominio della soluzione: il design
Dominio del problema Dominio della soluzione mission analisi design implementazione Mondo delle soluzioni problema analista sviluppatore cliente 7/1/03

62 3: Design Dato il “cosa deve fare X” (=analisi)
mission mission design Dato il “cosa deve fare X” (=analisi) il design specifica come deve essere fatto, il design è il progetto dell’implementazione È come il progetto della casa (costruireste una casa senza il progetto) Il design discende dall’analisi (tracciamento) Per ogni requisito o gruppo di requisiti occorre specificare un insieme di specifiche di realizzazione Attenzione alle incoerenze: (es. la coppia) 7/1/03

63 Esempio di design (la penna)
R1: La penna dovrà scrivere per almeno un chilometro di carta D1: la penna conterrà 10 ml di inchiostro D2: la penna sarà a sfera con sfera di acciaio inox R2: La penna dovrà avere un costo di produzione inferiore a 1 € D3:i materiali di produzione saranno … R3: La penna dovrà avere una impugnatura giudicata comoda per almeno il 70% degli utilizzatori D4: L’impugnatura sarà di tipo … R4: La penna dovrà scrivere in inchiostro blu o rosso D5… R5: La penna dovrà funzionare fra 0° e i 40° gradi D6 l’inchiostro sarà di tipo R6: La penna dovrà avere un costo di produzione inferiore a 1 € D1, D2, D3,D4,... 7/1/03

64 Esercizio a squadre sul design
Definire mission e analisi e design e test : organizzare un ristorante progettare uno scanner progettare uno una videocamera valutare criticamente il lavoro altrui 7/1/03

65 Validazione del design
E’ in linea con l’analisi ? tracciare ogni componente del design sui requisiti di analisi Fattibilità Siamo in grado di farlo ? Abbiamo il tempo i soldi le capacità le persone giuste Accettabilità Ci conviene farlo ? Otteniamo qualcosa di soddisfacente come performance Vulnerabilità qualsiasi cosa che può andar male andrà male i rischi / conseguenze della scelta implementativa 7/1/03

66 Design iterativo Il primo design è fondamentale ma è sbagliato !!
Il design (specialmente nel sw) va fatto considerando una prima soluzione , migliorandola successivamente 5 design: quasi inutile 3 design: si svolta 100% 6 design: inutile efficacia 4 design: si migliora poco 2 design tempo 1 design: sbagliato ma utile 7/1/03

67 Migliorare il design le iterazioni successive possono migliorare:
tempi di sviluppo risorse impiegate costi di sviluppo qualità del prodotto affidabilità del prodotto le iterazioni successive possono ridurre i rischi: 7/1/03

68 Esercizio a squadre sul design
Definire mission e analisi e design e test : progettare uno un telefonino comprare un telefonino progettare una radio per la macchina organizzare una festa valutare criticamente il lavoro altrui 7/1/03

69 Implementazione Realizzazione del progetto di design
Per il software coincide con la codifica Deve essere in linea con il design Se vi sono problemi con il design, aggiornare il design e eventualmente l’analisi 7/1/03

70 Test La fase di test serve a verificare se ho raggiunto obiettivi:
E’ composta da Verifica e Validazione Verifica :stiamo costruendo un prodotto bene (implementazione soddisfa il design) Si definiscono una serie di test per verificare che il prodotto funziona Validazione : stiamo costruendo il prodotto giusto ? è efficacie ? È quello che ha chiesto il cliente si definiscono una serie di test che discendono dai requisiti e si verificano Verificare che i requisiti di analisi del cliente siano soddisfatti nel prodotto finale 7/1/03

71 Esempio di test Verifica Validazione
la penna non si deve rompere quando scrive non discende dai requisiti del cliente ma comunque è un test importante di funzionalità) Validazione R5: La penna dovrà funzionare fra 0° e i 40° Metto la penna in un frigo a 0° per 10 minuti e provo a scrivere Metto la penna in un forno a 40° per 10 minuti e provo a scrivere Il test è collegato a collaudi, pagamenti e alle penali esempio: Penali al secondo 7/1/03

72 Esercizi definire mission, analisi, design, implementazione, test per i seguenti problemi: un videotelefono un sistema di domotica un dvd recorder un ponte radio un modem telefonico un ristorante 7/1/03

73 Come si gestisce un progetto / problema
definire gli obiettivi del progetto creare il piano del progetto (inizio progetto) controllare il progetto (durante il progetto) chiudere il progetto start pianifico Eseguo task fine monitorizzo Aggiorno piani nuovi Quando finisce ? controllo 7/1/03

74 Fasi per la creazione di un piano
7/1/03

75 Creare il piano del progetto
prima di iniziare un progetto si deve definire una pianificazione: la pianificazione scompone l’attività principale in sottoattività per ogni attività nome responsabile data inizio/ fine (ore uomo richieste/ disponibili) vincoli temporali prerequisiti i piani vengono descritti attraverso un Gannt 7/1/03

76 Esercitazione sui Gannt
scadenze, barre attività vincoli Creare il Gannt di un video gioco definire i task, risorse, ... modifiche sul Gannt cambiare risorse livellare uso delle risorse attività critiche percorso critico 7/1/03

77 Gannt di un video gioco 7/1/03

78 Controllo definire le misure per il controllo misurare periodicamente
percentuale di lavoro finito la curva di fine 7/1/03

79 controllo definire le misure di controllo
verificare le previsioni con le misure attuali i ritardi: strategie di recovery curve di risposta tempo % concluso 100% fine controlli 7/1/03

80 Problemi della pianificazione/controllo
valutazione delle prestazioni della risorsa disponibilità risorse percorso critico compatibilità con le scadenze priorità vincoli forward scheduling backward scheduling 7/1/03

81 Verificare i ritardi Fine reale previsione controlli Misura reale oggi
100% controlli % concluso Misura reale Fine teorica oggi 7/1/03

82 Esercitazioni domande
Definire il piano per ottenere l’output della esercitazione definire i tempi e i controlli il piano degli esami il piano per la progettazione del software il piano per la progettazione dell’organizzazione festa il piano organizzazione vacanze il piano start up di un ristorante il piano di start up di un sito web domande quali assunzioni quali dati di input quali vincoli come si controlla, quali misure i tempi sono stati rispettati 7/1/03

83 Fasi del progetto: Harvard Business School
7/1/03

84 Obiettivi raggiunti Da ricordare essere capaci di :
le fasi della progettazione Mission, analisi, design, implementazione, test cosa è la mission la differenza fra analisi e design (cioè cosa fare e come realizzarlo) il test essere capaci di : definire le fasi di progetto e il test per un generico problema definire la pianificazione di un progetto definire le metodologie di controllo 7/1/03

85 Ciclo di vita del software gerarchie
Lezione 4 Ciclo di vita del software gerarchie Più che una disciplina o un corpo di conoscenza, l’ingegneria è un modo di affrontare un problema Scott Whitmire 7/1/03

86 Modelli del processo software
Ciclo di vita di un progetto software = Modello e sequenza delle attività di sviluppo. Tipi di modelli: Il modello sequenziale lineare (“modello a cascata” o gran design) Il modello basato sulla prototipazione Il modello RAD (Rapid Application Development) Modelli evolutivi Il modello incrementale Il modello a spirale Il modello ad assemblaggio di componenti 7/1/03

87 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 dominio delle informazioni, funzionalità, comportamento, prestazioni, interfacce strutture di dati, architettura del software, interfacce, algoritmi delle operazioni codice Problemi: i progetti reali non si conformano allo schema sequenziale ogni modifica nello schema può causare confusioni non può essere governata l’incompletezza dei requisiti versione funzionante solo verso la fine del progetto “stati bloccanti” per colpa della sincronizzazione tra le attività o tra i membri del team 7/1/03

88 Sviluppo evolutivo Problema: soluzione
non c’è tempo di fornire una release che copra tutti i requisiti i requisiti sono incompleti soluzione sviluppo in sequenza prototipi sempre più completi i prototipi implementano sottoinsiemi di requisiti non congelati il cliente approva o modifica le implementazioni del prototipo Vantaggi dello sviluppo iterativo È pianificato e gestito È prevedibile Permette variazioni dei requisiti più facilmente È basato su prototipi eseguibili evolutivi e non solo documentati Implica il cliente nell’arco dell’intero processo È guidato da rischi 7/1/03

89 Sviluppo evolutivo del software
1. Non c’è tempo per una versione completa però dobbiamo uscire sul mercato. 2. Esiste un nucleo di requisiti di sistema ma i dettagli delle estensioni non esistono ancora. Soluzione: modello di processo per un prodotto che evolve nel tempo Definire l’output del sistema Specificare l’incremento del sistema Costruire l’incremento del sistema Collaudare l’incremento del sistema Rilasciare l’incremento del sistema Sistema è completo? Completare il rilascio del sistema 7/1/03

90 Strutturazione del sistema
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 Stadio 2 Consegna dello stadio 2 Analisi Codifica Collaudo Proget tazione Stadio 3 Consegna dello stadio 3 Analisi Codifica Collaudo Si partizionano i requisiti in tre stadi a seconda delle priorità 7/1/03

91 Modello a spirale Sei attività portanti (task region): Pianificazione
Analisi dei rischi Strutturazione Costruzione e rilascio Comunicazioni con il cliente Valutazione da parte del cliente Asse dei punti di entrata Progetti di sviluppo di nuove 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. 7/1/03

92 Modello ad assemblaggio di componenti
Pianificazione Analisi dei rischi Comunicazioni con il cliente Strutturazione Costruzione e rilascio Valutazione da parte del cliente Individuazione componenti candidati Ricerca componenti nella libreria Estrazione componenti disponibili Costruzione componenti non disponibili Inserimento nuovi componenti nella libreria Costruzione n-esima iterazione del sistema 7/1/03

93 modello di sviluppo RAD
consentono un tempo di sviluppo molto ridotto il modello di sviluppo è : analisi Business modelling: definizione dei flussi informativi e dei processi Data modelling process modelling design / implementation application generation: direttamente con il tool di 4g. Molto del codice è già implementato nel tool testing limitato perchè la maggior parte del software è già sviluppato 7/1/03

94 Pro&contro del modello RAD
velocità affidabilità (il codice è per la maggior parte già sviluppato) contro adatto solo se esiste un tool RAD che implementa la maggior parte del codice per l’applicazione specifica non è facile particolareggiare il codice non è facile migliorare le performances spesso si ignorano i passi fondamentali della progettazione e quindi il risultato è disastroso 7/1/03

95 Riuso o sviluppo ex novo ?
Spesso sono disponibili componenti utili per lo sviluppo: debbono essere utilizzati ? Sviluppo ex novo costo riuso lavoro da effettuare in creazione o modifica 7/1/03

96 Riuso o sviluppo ex novo ?
Riduzione del ciclo di vita del software: come è ripartito fra le varie fasi ? 7/1/03

97 Analisi del costo di sviluppo
le fasi di debugging/ maintainance hanno il costo maggiore Occorre impostare Analisi, design e codifica nel progetto in modo da minimizzare il costo di debugging testing e manutenzione 7/1/03

98 Quale modello La scelta del modello è influenzata da vari fattori:
formalismo del progetto disponibilità di risorse disponibilità dei requisiti disponibilità del cliente disponibilità di codice preesistente RAD tools tempi e costi risorse (numero e skill) esercizio: quale modello scegliereste ? modello a cascata, evolutivo, incrementale, a spirale, assemblaggio di componenti, RAD 7/1/03

99 Seconda parte: gerarchie
Lezione 4 Seconda parte: gerarchie 7/1/03

100 Regola fondamentale: Divide et Impera !
Cosa avevano capito i Romani La mente umana è molto limitata il caso di Paolo d. (problema finanziario) /alessia M(psicologia nei problemi complessi) Problema Problema affrontabile 7/1/03

101 Implicazioni del divide et impera
divido il problema in sottoproblemi risolvibili risolvo un sottoproblema alla volta considerando gli altri risolti definire sottoproblemi mi aiuta a dividere il lavoro fra più persone Problema dato per risolto Problema da affrontare 7/1/03

102 Dal sistema al dettaglio:gerarchie e zoom
Divide et Impera ! Se il sistema è troppo complesso: 1) si definisce l’analisi del sistema (gerarchia uno) 2) si definiscono i sottosistemi (gerarchia due) 3) si definiscono le interfacce 4) si procede sul sottosistema come se fosse un sistema mission, analisi, design, .... Se i sottosistemi sono ancora troppo complessi si crea una altra gerarchia 7/1/03

103 Gerarchie Gerarchia 2 Mondo Interfaccia 1 Dato un sistema connesso con l’esterno da interfacce esterne, una gerarchia è composta da: sottosistemi che partizionano il sistema interfacce che connettono i sottosistemi le interfacce esterne che connettono i sottosistemi con il mondo esterno sistema Interfaccia 2 Interfaccia 1 sottosist sottosist Interfaccia 3 Interfaccia 4 sottosist Gerarchia 2 Gerarchia 3 sottosist 7/1/03

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

105 Coesione ed accoppiamento
Spettro della coesione Bassa Alta “Dispersivo” “Concentrato” Casuale Logica Temporale Procedurale Di comunicazione Sequenziale Funzionale Spettro dell’accoppiamento Bassa Alta Nessun accoppiamento diretto Accoppiamento di dati Accoppiamento a template Accoppiamento di controllo Accoppiamento esterno Accoppiamento comune Accoppiamento di contenuto 7/1/03

106 Esempio di definizione dei moduli
definire un design corretto e scorretto di modularizzazione 7/1/03

107 Determinazione del numero dei moduli
Quanti moduli devo fare il costo di un sistema è proporzionale alla complessità la complessità è data dalla somma della complessità intramodulo e della complessità delle interfacce intermoduli Complessità totale Complessità & costo Complessità delle interfacce= costo di integrazione Complessità dei modulo = costo per modulo Maggiore Granularità (+ moduli +piccoli) 7/1/03

108 Esempio: progettazione di una auto
auto troppo complessa! Divide et impera ! Definisco la mission progettare una auto utilitaria per l’Italia Definisco analisi del sistema auto R_auto_1: deve raggiungere la velocità di almeno 140 R _auto_ 2: deve lavorare fra -15° e +45° gradi R _auto_ 3: deve frenare da 50 km/h a 0km/h in 10 sec R _auto_ 4: deve avere 4 posti comodi definisco i sottosistemi (gerarchia di primo livello) motore, carrozzeria, ruote,freni, volante, cambio definisco le interfacce fra i sottosistemi 7/1/03

109 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 7/1/03

110 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 7/1/03

111 Regole per la costruzione della gerarchia
le interfacce definiscono i rapporti fra due sottosistemi le interfacce devono essere coerenti fra diverse gerarchie tutti i requisiti di un sistema si devono tradurre in requisiti per i sottosistemi lo zoom fra le varie gerarchie deve essere coerente a livello di interfacce e di contenuti 7/1/03

112 Coerenza delle gerarchie per le interfacce
gerarchia 1 contenuto Lazio interfacce esterne: A1 Napoli, A1 Firenze gerarchia 2 province del Lazio (Roma LT, FR, VT, RI) interfacce esterne: A1 Napoli (LT), A1 Firenze (FR) interfacce interne: RM LT (Pontina,...), RM VT (Cassia,...) gerarchia 3 comuni di Latina (Formia, Gaeta, ... LT, FR, VT, RI) non si devono perdere le interfacce 7/1/03

113 Gli attori gli attori sono tutte le entità che interagiscono con il sistema gli attori sono collegati con il sistema attraverso interfacce esterne gli attori non sono solo persone per il sottosistema motore gli attori sono: cambio(interfaccia albero di trasmissione) comandi utente (interfaccia filo acceleratore) 7/1/03

114 diagramma funzionale con attori
strada Gerarchia 1° livello guidatore interagisce comanda Auto guidatore Comandi auto Gerarchia 2° livello comanda strada interagisce freni Ruote Motore cambio 7/1/03

115 diagramma funzionale: 3° gerarchia
Comandi auto cambio Gerarchia 3° livello Invia rotazione gestisce Motore Comandi auto girano strada interagisce Ruote bloccano Freni Invia rotazione cambio 7/1/03

116 diagramma funzionale: 4° gerarchia
cambio Comandi auto Gerarchia 3° livello Invia rotazione gestisce Motore Comandi auto Gerarchia 4° livello gestisce controllo cambio Invia rotazione propulsore refrigeramento 7/1/03

117 Requisiti di interfaccia
Gerarchia 1: interfacce esterne comanda, interagisce: Gerarchia 2: interfacce interne girano, bloccano, invia rotazione Gerarchia 3: interfacce interne .... Le interfacce di una gerarchia vengono ereditate e eventualmente approfondite nelle gerarchie successive 7/1/03

118 Esercizio: il ristorante
definire mission analisi di sistema requisiti del sistema attori interfacce esterne e requisiti associati definire i sottosistemi (gerarchia di primo ordine) definire interfacce interne fra sottosistemi e requisiti associati associare interfacce esterne a sottosistemi analisi di sottosistema requisiti del sottosistema 7/1/03

119 Esercitazione: sistema gestione ordini e conto per ristoranti
mission: progettare un sistema informatico che gestisca gli ordini e il conto finale per ogni ristorante analisi di sistema requisiti del sistema attori interfacce esterne e requisiti associati definire i sottosistemi (gerarchia di primo ordine) definire interfacce interne fra sottosistemi e requisiti associati associare interfacce esterne a sottosistemi analisi di sottosistema requisiti del sottosistema 7/1/03

120 Obiettivi raggiunti individuare sottoproblemi (gerarchia 1)
saper scegliere il giusto modello di sviluppo in base alla tipologia di problema modello a cascata, evolutivo, incrementale, a spirale, assemblaggio di componenti, RAD per ogni problema essere capaci di : individuare sottoproblemi (gerarchia 1) determinare i sottosistemi in base alla complessità di interfaccia e di modulo definire interfacce esterne e interne associare e definire i sottorequisiti iterare il processo per il numero di gerarchie necessarie 7/1/03

121 Strumenti per l’analisi: diagrammi E/R, Use case, diagrammi di Eventi
Lezione 5 Strumenti per l’analisi: diagrammi E/R, Use case, diagrammi di Eventi 7/1/03

122 Le fasi della progettazione
Mission Analisi Design Implement. Test 7/1/03

123 Attività di analisi 1: Comprensione del problema: Requisiti.
2: utilizzo del sistema dal punto di vista utente: casi d’uso. 3: Modellazione. 4: Specifica 5: Riesame. 7/1/03

124 Attività di analisi : 1 1: Comprensione del problema: Requisiti.
Per mezzo di interazioni e discussioni con l’utente e dello studio della specifica del sistema e del piano di progetto (se ci sono!), l’analista raccoglie i requisiti. Requisiti: descrizione di come il cliente o l’utente desidera essere il sistema. Gli elementi acquisiti dall’analista sono: una descrizione del sistema gli attori del sistema gli obiettivi del sistema le funzioni del sistema gli attributi del sistema 2: utilizzo del sistema dal punto di vista utente: casi d’uso. Per chiarire a sè e all’utente il sistema da progettare, l’analista descrive come il sistema verrà utilizzato dall’utente attraverso i casi d’uso. I casi d’uso sono scenari che mostrano l’utilizzo del sistema in situazioni specifiche 7/1/03

125 Attività di analisi : 2 3: Modellazione. L’analista definisce le gerarchie e per ogni gerarchia definisce i vari modelli: Entità/Relazione, funzionale, di stato del sistema nel tentativo di cogliere la struttura, il contenuto informativo, il flusso di dati e del controllo e l’operatività del sistema. 4: Specifica. Requisiti, gerarchie, casi d’uso, modelli E/R, funzionali e di stato vengono riorganizzati e ingegnerizzati. 5: Riesame. Verifica della completezza, consistenza e accuratezza della specifica. 7/1/03

126 Strumenti di analisi 1: Comprensione del problema 
Requisiti  2: utilizzo del sistema dal punto di vista utente casi d’uso 3 Modellazione gerarchie  modelli dei dati (E/R) modelli funzionali  diagrammi di stato diagrammi di interazione (eventi) 4: Specifica. ingegnerizzazione dei requisiti e modelli 5 Riesame 7/1/03

127 Modello dei dati Descrive il mondo dei dati del problema dal punto di vista dell’analisi elementi di un modello di dati: oggetti attributi:sono i dati di un oggetto (=descrivono caratteristiche oggetto e riferimenti ad altri oggetti) Relazioni: definiscono i collegamenti fra oggetti (approfondite quando si parlerà di OO) cardinalità: numero di occorrenze di oggetti in una data relazione 7/1/03

128 Diagrammi E/R (notazione UML)
Oggetto attributo 1 (ID) attributo 2.. Oggetto attributo 1 (ID) attributo 2.. Nome relazione * 1..n Cardinalità Relazione 7/1/03

129 sistema gestione ordini e conto per ristoranti (GOCR):gerarchia 1°
mission: progettare un sistema informatico che gestisca gli ordini e il conto finale per ogni ristorante Cameriere Cliente Ordini/ conti cucina Sistema Gocr Ordini pietanze Stampa conto Analisi scorte Gestore approvvigionamenti cassa 7/1/03

130 GOCR gerarchia 2° (struttura dati)
Pietanza ID tipo Prezzo Quantità richiesta ID Pietanza ID ingrediente quantità Singolo ord. ID ordine id pietanza quantità ingrediente ID quantità disponibile Ordine ID ID Tavolo Ora gestito da Tavolo ID stato Cameriere ID Nome conoscete MS Access ? 7/1/03

131 Modello in Access 7/1/03

132 Diagrammi E/R Criteri per la progettazione
Eliminazione dei percorsi ciclici Eliminare la ridondanza dei dati /relazioni Cercare la max semplicità Minimo numero di records e di relazioni per il problema in esame Non confondere E/R (senza info di tempo ) con l’ordine di inserimento dei dati nel database Navigare le relazioni per valutare coerenza Valuare i costi di scelta “ attributo o relazione ?” NO colonne variabili !!! 7/1/03

133 GOCR gerarchia 2° (struttura funzionale)
cassa Cameriere conti Gestione conti cucina Preparazione pietanze Calcolo conti Gestione ordini Gestione scorte Gestore scorte 7/1/03

134 Diagramma di stato (stato tavoli) : esercitazione
Convenzione UML Esercizio: identificare stati libero,attesa ordine, in_consumazione,richiesta conto identificare transazioni start stato transizione 7/1/03

135 esercizio: segreteria telefonica
Identificare gli stati e le conessioni 7/1/03

136 Use cases: Attori Professore Operatore Gestore Utente sistema 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 Studente Cliente di banca Operatore Bancomat Sistema informatico bancario BANCOMAT Sistema paghe 7/1/03

137 Casi d’uso (use cases) Specifica di un comportamento di un sistema
Un caso d’uso è una modo per utilizzare un sistema, o anche uno schema del suo comportamento. Descrive una sequenza di azioni, che il sistema compie come risposta agli stimoli ricevuti da vari attori e che si materializza in un risultato che serve ad un attore, quello che ha iniziato il caso. I casi d’uso non contengono informazioni su come realizzare il comportamento. Un caso d’uso descrive un’insieme di sequenze, in cui ciascun sequenza rappresenta l’interazione di entità esterne al sistema (attori) con il sistema.. Un caso d’uso rappresenta un requisito funzionale dell’intero sistema. É il contenuto base del manuale utente 7/1/03

138 Circoscrizione::Richiesta di certificato
Casi d’uso Gestione Corso Gestione Piano Corsi Circoscrizione::Richiesta di certificato semplice nome nome con percorso 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 Prelevamento Cliente della banca 7/1/03

139 Come scrivere un caso d’uso
1. Viene creato un documento di flusso di eventi per ciascun caso d’uso. Il documento è scritto dal punto di vista di un attore. 2. Viene dettagliato che cosa il sistema deve rilasciare all’attore quando il caso d’uso viene eseguito. Tipicamente il documento contiene: Come inizia e come si termina il caso d’uso Il flusso normale di eventi I flussi alternativi di eventi I flussi straordinari di eventi Caso d’uso Nome: Attori: Precondizioni: Postcondizioni: Descrizione: Eccezioni: 7/1/03

140 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 Quando …. Un caso d’uso descrive un insieme di sequenze di eventi che sono varianti nello stesso caso. Ciascuna sequenza rappresenta uno scenario. Uno scenario è rispetto ad un caso d’uso come un‘istanza rispetto alla classe. 7/1/03

141 Caso d’uso: telefonata con il telefonino
Nome: telefonata con tel Attori: utente Precondizioni: acceso Postcondizioni: Descrizione: Eccezioni: l’utente spinge i bottoni del numero di telefono richiesto l’utente aspetta un segnale se libero aspetta .... ... 7/1/03

142 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. Studente Gestione Piano di Studi Sistema di tasse Professore Richiesta Corso Operatore Gestione Piano Semestrale 7/1/03

143 Identificazione dei casi d’uso
1 . Identificare gli attori. 2 . Intervistare gli utenti tipici. 3 . Riflettere sui modi fondamentalmente differenti in cui ciascun attore utilizza il sistema. 4 . Raggruppare gli scenari che sono simili e di cui l’utente parla come fossero variazioni su una unica tema. 5 . Denominare i casi d’uso e fornire una descrizione. 6 . Cercare i frammenti comuni tra i differenti casi d’uso e fattorizzarli in casi d’uso di base e aggiunti. 7 . Associare ad ogni caso d’uso un valore di priorità. 7/1/03

144 Diagramma di eventi I diagrammi di interazioni descrivono come vengono realizzati i casi di uso attraverso le interazioni tra oggetti. Contiene un’insieme di messaggi interscambiati tra un insieme di oggetti in un certo ambiente (sistema, sottosistema ecc.) per compiere un certo obiettivo. Quando due oggetti sono connessi tra loro, c’è un caso d’interazione. Un diagramma di sequenze di eventi mostra un’interazione disposta in ordine cronologico. Mostra gli oggetti partecipanti all’interazione con le loro linee di vita e i messaggi scambiati in ordine cronologico. Messaggio - specifica di una comunicazione tra oggetti, trasporta un’informazione con l’intento di far scattare un’attività 7/1/03

145 Diagrammi di sequenze (=di eventi)
Oggetto “Linea della vita” dell’oggetto rappresenta l’esistenza dell’oggetto o dell’attore Messaggio - call - return - send - create - destroy {b-a<5sec} Attivazione Mostra il periodo in cui un oggetto realizza un’azione etichetta b Vincolo Tempo della transizione telefonino utente interlocutore Digita numero a chiamata Risposta libera {b-a<2sec} b risponde Voce inter. c Tempo 7/1/03

146 sistema gestione ordini e conto
mission: progettare un sistema informatico che gestisca gli ordini e il conto finale per ogni ristorante definire diagramma eventi per ordini e conto finale Cameriere Cliente Ordini/ conti cucina Sistema Gocr Ordini pietanze Stampa conto Analisi scorte Gestore approvvigionamenti cassa 7/1/03

147 Esercizio diagramma di sequenza per GOCR
Cameriere cucina cassa Sistema Gocr 7/1/03

148 Esercizio: organizzo una vacanza
Tour operator agenzia amici 7/1/03

149 Obiettivi raggiunti Da ricordare
gli strumenti a disposizione dell’analisi Per qualsiasi problema essere capaci di : individuare gli strumenti di analisi necessari E/R, Use case diagramma di eventi, diagramma funzionale, diagrammi di stato individuare quali strumenti non sono necessari saper modellare la struttura dati (E/R) saper definire gli stati interni se necessario (diag. di stato) saper creare un caso d’uso saper descrivere una interfaccia con gli strumenti di analisi 7/1/03