La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


Presentazione sul tema: "Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza 7/1/03 Progettazione di Apparati e Sistemi di TLC Prof. Claudio Becchetti Laboratorio."— Transcript della presentazione:

1

2 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza 7/1/03 Progettazione di Apparati e Sistemi di TLC Prof. Claudio Becchetti Laboratorio

3 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -2 7/1/03 Lezione 1 Progettazione: il problema tipico

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

5 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -4 7/1/03 metodo di valutazione l la valutazione si basa su: n voto di gruppo, n Voto di coppia (tesina) n Esame individuale l Tesina: il vostro background ?

6 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -5 7/1/03 Preparazione individuale l corsi sulla progettazione del software l corsi su TLC l conoscenze Object oriented l conoscenze linguaggi di programmazione l Elettronica l bioingegneria l problem solving ?

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

8 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -7 7/1/03 Altri testi l Articoli n No silver bullets, essence and accidents of software engineering, Brooks F. P., Computer (Apr. 1987). n Building bug-free O-O software: An introduction to Design by Contract, Meyer B., available in n 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

9 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -8 7/1/03 testi opzionali n Analisi Strutturata dei Sistemi, E. Yourdon. Jackson Italia, 1990 n The C++ Programming Language, third edition, Stroustrup B., Addison-Wesley (1997).. n Speech Recognition : Theory and C++ implementation, Becchetti C., Prina L., John Wile & Sons, 1999 n Borland C Object-Oriented Programming, Cantù M., Tendon S., Random House/Borland Press (1995) n Cline M. P., Lomow G. A., C++ Faqs, Addison Wesley (1995).

10 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -9 7/1/03 Presentazione del corso l Corso di progettazione n focus sulla progettazione in generale u focus sulla progettazione del software u focus sui sistemi di telecomunicazione (TLC) u focus su Object Oriented (OO) e C++ l Perché focus sulla progettazione ? n La progettazione è uno strumento per il problem solving – esempio paolo

11 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -10 7/1/03 a cosa vi serve veramente questo corso ? n Non progetterete mai ? n Non svilupperete mai il sw ? n non vi occuperete mai di TLC ? n Il C++ sarà superato n lobject oriented non serve ? n Dopo un mese dallesame vi sarete dimenticati tutte le nozioni apprese ? l Il corso è indirizzato alla progettazione secondo le esigenze del mondo del lavoro n progettare significa risolvere i problemi (problem solving)

12 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -11 7/1/03 cosa vede una società da un neolaureato anche brillante n un elemento grezzo da formare n a seconda dei lavori occorrono nellordine dei 12 mesi perché un neolaureato sia operativo n nei primi 12 mesi il neolaureato non è in grado di fare quasi nulla per lindustria n per rendere operativo un neolaureato, occorre molto addestramento (training on the job ) l lorganizzazione cerca di insegnare il problem solving nella fase di addestramento

13 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -12 7/1/03 cosa vorrebbe lindustria da un neolaureato u capacità di analizzare e risolvere problemi/lavori complessi e nuovi u capacità di rispettare i vincoli del problema (tempi, costi e risorse disponibili) u capacità di rispettare i vincoli per risolvere il problema (tempi costi e risorse disponibili) u a prescindere dal settore di impiego (software, tlc, gestionale, marketing,...) n Quindi -> problem solving: u capacità di portare a termine con profitto un lavoro in maniera autonoma

14 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -13 7/1/03 Problem solving e capacità di progettare: serve solo nel lavoro? Lavoro da fare Problema da risolvere Vincoli tempi costi risorse Problema risolto lavoro concluso Lavoro ben fatto soluzione adeguata

15 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -14 7/1/03 Problem solving: dove ? u creare un sistema tlc u organizzare una vacanza u Aprire un ristorante u produrre un software u creare un nuovo prodotto u organizzare una festa u organizzare una vacanza u lasciare la ragazza? l Il problem solving serve ovunque si presenti un problema/ lavoro: n 1) importante n 2) di complessità non banale

16 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -15 7/1/03 Problem solving e progettazione l Ogni volta che dobbiamo risolvere un problema o fare un lavoro importante occorre: l progettare il lavoro/ la soluzione l Progettare significa stabilire: u cosa bisogna fare u Come implementarlo u In che tempi u Con che risorse u Come verificare cosa si è implementato l la capacità di problem solving si acquisisce imparando a progettare

17 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -16 7/1/03 La progettazione e il corso l lo scopo del corso è di insegnare a progettare n vi verranno insegnate nel corso le tecniche di progettazione che dovrete applicare a casi concreti u le tecniche di progettazione servono solo nel mondo del lavoro ? u le tecniche di progettazione servono solo nel campo del software TLC ?

18 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -17 7/1/03 Praticone o Progettista ? l Esempio: n Le istruzioni della cinepresa nuova: Leggete le istruzioni o usate subito la cinepresa ? Tempo % Funzionamento compreso 0 % 100 % Fine task ?

19 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -18 7/1/03 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

20 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -19 7/1/03 Esempio: l Esempio del viaggio l la mia organizzazione della settimana bianca l e io intanto prenoto ( esempio rosanna ) lUsa la testa non le gambe

21 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -20 7/1/03 Schema di un problema Cliente Input Output Task fornisce controlla Progetta, pianifica, esegue affida vincoli esecutore Le definizioni ?

22 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -21 7/1/03 Definizioni l Task n tutto le operazioni che devo compiere per ottenere loutput l Input n tutto ciò che posso o devo prendere dallambiente esterno per portare a termine il task, u informazioni (dati, scadenze, costi, tempi) u risorse (mezzi fisici, persone, soldi) l Vincoli n possono impedire la soluzione del task (vincoli incrociati)

23 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -22 7/1/03 Definizioni (output e test) l Output n il risultato del mio lavoro: u informazioni, servizi, mezzi trasformati, documenti, progetti, software... l Test n metodi implementati da me o dal mondo esterno per verificare che loutput sia adeguato l Cliente n chi mi chiede di: u risolvere un problema u definire delle soluzioni u portare a termine una attività

24 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -23 7/1/03 identificazione di input output e task e test l Esercitazione n creare una tabella a 5 colonne : nome del task come di seguito, input, vincoli, descrizione task, output, test) u creazione video gioco software n lavoro di gruppo u progettazione di un telefonino u produzione di un telefonino u organizzazione di un concerto u organizzazione di una vacanza con un gruppo di amici l quale è la differenza fra input e vincolo ?

25 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -24 7/1/03 LInvariante di Input e vincoli l tutti i problemi implicano n tempi di realizzazione (cioè pianificazione controllo) n costi (budget a disposizione) n risorse (umane, materiali) l per affrontare un problema/ progettazione occorre definire sempre chiaramente i tre aspetti

26 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -25 7/1/03 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. l

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

28 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -27 7/1/03 Assunzioni l Lassunzione deve essere: n plausibile nel contesto del task n esplicitata (deve essere menzionata da qualche parte) n Le assunzioni sono spesso collegate ai soldi e sono fondamentali per la buona riuscita di un progetto (ref. il registro delle assunzioni) l Le assunzioni servono a n Ridurre il numero di possibilità di design n Semplificare n Limitare e vincolare il task (loggetto non farà questo) n Definire delle preferenze (p.es. linguaggio usato) n eliminare i vincoli

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

30 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -29 7/1/03 Schema del corso l parte 1 ; le fasi della progettazione l parte 2 : la progettazione strutturata l parte 3: la progettazione a oggetti e classi l parte 4: la progettazione object oriented

31 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -30 7/1/03 le fasi della progettazione l Progettare X significa stabilire: n 1: Mission (cosa è X e purché faccio X ) n 2: Analisi (cosa fa X ) n 3: Design (come realizzo X ) n 4: Implementazione (X realizzato) n 5: Test (X realizzato funziona ? È adeguato ? : u Rispetta design (è come lo volevo implementare) u Rispetta analisi (fa ciò che avevo progettato di fargli fare) u Rispetta la mission (soddisfa il motivo per cui lo avevo fatto)

32 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -31 7/1/03 Capacità acquisite nella prima lezione l dato un problema qualsiasi: n identificare u input u vincoli u output u task u cliente u test n individuare input incompleti/vincoli incrociati n definire assunzioni plausibili individuare i rischi

33 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -32 7/1/03 Lezione 2 le fasi della progettazione: la mission, lanalisi

34 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -33 7/1/03 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

35 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -34 7/1/03 Perché progettare ? l Progettare è frustrante n Allinizio si raggiungono risultati più lentamente n È una attività impegnativa perché richiede forte uso di attività concettuale invece si tende a prediligere attività celebrale manuale n Stanca più velocemente l progettare è vincente n Garantisce il risultato giusto in tempi certi n Il tempo impiegato è molto inferiore rispetto allapproccio da code and fix. l Usa la testa e non le gambe

36 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -35 7/1/03 Perché imparare a progettare Secondo la letteratura scientifica, un personale ben addestrato può lavorare fino a 25 volte di più rispetto ad un personale non sufficientemente adeguato nell'ambito del software. (Negli altri settori il differenziale di produttività si limita ad un fattore 4 ). l La differenza di prestazioni fra due operatori del software è spesso dovuta ad una differente capacità di progettazione l Riduzione del ciclo di vita del software: come è ripartito fra le varie fasi ?

37 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -36 7/1/03 Non progettare nel software e nelle TLC l Non progettare significa: n I tempi per concludere un task possono dilatarsi allinfinito (comune nella codifica del software) n Non si sa mai quando si finisce (per fare il 5% del lavoro occorre il 95 % del tempo ?) n La qualità del prodotto è bassa, richiede normalmente rilavorazioni per correggere errori n Il prodotto può essere gestito solo da chi lo ha creato

38 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -37 7/1/03 Praticone o Progettista ? l Esempio: n Le istruzioni della cinepresa nuova: Leggete le istruzioni o usate subito la cinepresa ? Tempo % Funzionamento compreso 0 % 100 % Fine task ?

39 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -38 7/1/03 Parte prima: le fasi della progettazione l Progettare X significa stabilire: n 1: Mission (cosa è X e purché faccio X ) n 2: Analisi (cosa fa X ) n 3: Design (come realizzo X ) n 4: Implementazione (X realizzato) n 5: Test (X realizzato funziona ? È adeguato ? : u Rispetta design (è come lo volevo implementare) u Rispetta analisi (fa ciò che avevo progettato di fargli fare) u Rispetta la mission (soddisfa il motivo per cui lo avevo fatto) l Case study: la penna

40 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -39 7/1/03 Le fasi della progettazione Mission Analisi Design Implement. Test

41 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -40 7/1/03 1: Mission l Indica la meta, la direzione e lo scopo del task che si vuole compiere l È espresso in forma concisa (max 3 righe) l Serve a eliminare i problemi di framework n Esempio di framework (es. la Russia in sede ) l E un contratto con il cliente: n Va concordato con il cliente n È focalizzato sui bisogni del cliente è difficile da individuare è difficile da seguire

42 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -41 7/1/03 Lost the mission-> Fired ! l Perdere la mission può far licenziare ( esempio ) l la mission deve essere sintetica: le mission nelle aziende n 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 n Coca cola u The Coca-Cola Company exists to benefit and refresh everyone who is touched by our business. l Esercizio: n trovare alcune mission la Fiat, Xerox, IBM, HP, un teatro

43 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -42 7/1/03 Esempi di mission n Il cliente chiede: progettami una penna n Mission: progettare un oggetto in grado di scrivere indelebilmente sulla carta l Quali assunzioni ? l Esercizio definire la mission per n la progettazione di un centralino telefonico per piccole aziende, n la progettazione di gioco per play station, n la progettazione di un video telefono mobile. l Quali assunzioni ?

44 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -43 7/1/03 2: Analisi l Specifica che cosa deve fare il prodotto/servizio indicato nella mission l Deve discendere ed essere coerente con la mission n Esempio di incoerenza fra mission e analisi (la coppia faffi) l E una lista di requisiti secondo il punto di vista del cliente utilizzatore l se non si è capaci di fare analisi non si è capaci di codificare il software

45 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -44 7/1/03 I requisiti l I requisiti sono un qualcosa desiderato dal cliente espresso in forma di frase testuale n I requisiti dovrebbero essere numerati n I requisiti dovrebbero essere testabili n I requisiti dovrebbero essere univoci,non sovrapponibili, non ambigui n I requisiti dovrebbero coprire completamente i desiderata del cliente l i requisiti sono definiti dallanalista in base alle richieste del cliente, o sono direttamente forniti dal cliente

46 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -45 7/1/03 Esempio di requisiti l Le penna: n Mission: progettare una penna per scrivere sulla carta n Requisiti: 1. La penna dovrà scrivere per almeno un chilometro di carta 2. La penna dovrà avere un costo di produzione inferiore a 1 3. La penna dovrà avere una impugnatura giudicata comoda per almeno il 70% degli utilizzatori 4. La penna dovrà scrivere in inchiostro blu o rosso 5. La penna dovrà funzionare fra 0° e i 40°

47 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -46 7/1/03 Validazione dei requisiti l Il cliente dà spesso requisiti ambigui/incompleti l lanalista li trasforma in modo che i requisiti siano: n numerati n testabili u Definire un test per i precedenti requisiti n Non sovrapposti n Coprano completamente i desiderata del cliente

48 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -47 7/1/03 Esempio di requisiti non corretti l Dash lava più bianco !: come si testa ? l Requisiti: 1. La penna dovrà scrivere a lungo 2. La penna dovrà scrivere per almeno un chilometro di carta 3. La penna dovrà costare poco 4. La penna dovrà avere un costo di produzione inferiore a 1 5. La penna dovrà avere una impugnatura adeguata 6. La penna dovrà scrivere bene

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

50 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -49 7/1/03 Gli errori dellanalista l Esempio di errore n esempio della pennae del software () l Errore tipico e grave: n inserire nellanalisi di X come va fatto X (=design) n quali sono le implicazioni di questo errore ? n Lerrore ha impatto su costi tempi e risorse ?

51 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -50 7/1/03 Gli errori dellanalista 2 l esempio: una società di consulenza invia un ingegnere neolaureato ad un corso approfondito di analisi UML l lingegnere fa grande esperienza di analisi l la società di consulenza deve effettuare un lavoro di informatizzazione presso una azienda e decide di inviare lingegnere per il lavoro di analisi l quali sono i problemi che incontrerà lingegnere ? n 1:esempio n 2:esempio

52 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -51 7/1/03 Il dominio del problema e della soluzione missionanalisidesignimplementazione Dominio della soluzioneDominio del problema clienteanalista problema sviluppatore Mondo delle soluzioni

53 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -52 7/1/03 conclusione sugli errori l lanalista non deve confondere analisi con design l lanalista deve conoscere il dominio del problema l lanalista deve conoscere il dominio della soluzione

54 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -53 7/1/03 Esercizio ricapitolativo sulla analisi l Definire mission e analisi per i seguenti problemi, per ogni requisito definire un test n Uno scanner n Una videocamera n Un telefonino n Una radio n Un programma di posta elettronica n Un ristorante n Una festa

55 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -54 7/1/03 Progetto di una festa l Il committente richiede un festa l Lorganizzatore chiede come organizzarla l Il committente risponde: limportante è che ci divertiamo n Requisito: divertirsi ? u Testabile ? (il cliente mi paga se si è divertito ?) n Cosa fa lorganizzatore ?

56 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -55 7/1/03 Obiettivi raggiunti l dato un problema qualsiasi bisogna essere in grado di: n definire la mission (max 3 righe): n definire lanalisi: u definire i requisiti – evitare i requisiti scorretti – definire i test dei requisiti u evitare gli errori dellanalista: – non immettere il design nellanalisi – capire il dominio del problema – capire il dominio della soluzione

57 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -56 7/1/03 Lezione 3 Design

58 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -57 7/1/03 fallimento dei progetti software l in che cosa falliscono ? n funzioni, tempi e costi previsti l quanti progetti falliscono ? n 16% successo n 53% successo solo parziale n 31% fallimento e cancellazione – Studio dello Standish Group 1994 su 8380 progetti l le percentuali di fallimento sono superiori per progetti di dimensioni maggiori

59 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -58 7/1/03 Perché i progetti falliscono 1: Requisiti incompleti 13.1% 2: mancato coinvolgimento dellutente12.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% l A quali fasi riconducete i fallimenti

60 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -59 7/1/03 tipologie dei requisiti l tipologie di requisiti n funzionali deve fare n tecnologicideve usare tec. n Temporalideve metterci n economicideve costare n organizzativideve essere organizzato n prestazionali n relativi allutilizzodeve essere usato n alla sicurezza

61 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -60 7/1/03 Storia di un progetto Ciò che ha chiesto il cliente Ciò che ha capito il commerciale Come ha risolto il problema la progettazione Ciò che ha realizzato la fabbricazione Come hanno rimediato ai problemi i responsabili del montaggio Ciò che realmente voleva il cliente

62 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -61 7/1/03 Il dominio della soluzione: il design missionanalisidesignimplementazione Dominio della soluzioneDominio del problema clienteanalista problema sviluppatore Mondo delle soluzioni

63 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -62 7/1/03 3: Design l Dato il cosa deve fare X (=analisi) l il design specifica come deve essere fatto, l il design è il progetto dellimplementazione n È come il progetto della casa (costruireste una casa senza il progetto) l Il design discende dallanalisi (tracciamento) n Per ogni requisito o gruppo di requisiti occorre specificare un insieme di specifiche di realizzazione l Attenzione alle incoerenze: (es. la coppia) mission design

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

65 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -64 7/1/03 Esercizio a squadre sul design l Definire mission e analisi e design e test : n organizzare un ristorante n progettare uno scanner n progettare uno una videocamera l valutare criticamente il lavoro altrui

66 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -65 7/1/03 Validazione del design l E in linea con lanalisi ? n tracciare ogni componente del design sui requisiti di analisi l Fattibilità n Siamo in grado di farlo ? u Abbiamo il tempo i soldi le capacità le persone giuste l Accettabilità n Ci conviene farlo ? u Otteniamo qualcosa di soddisfacente come performance l Vulnerabilità u qualsiasi cosa che può andar male andrà male u i rischi / conseguenze della scelta implementativa

67 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -66 7/1/03 Design iterativo l Il primo design è fondamentale ma è sbagliato !! n Il design (specialmente nel sw) va fatto considerando una prima soluzione, migliorandola successivamente tempo efficacia 1 design: sbagliato ma utile 2 design 3 design: si svolta 4 design: si migliora poco 5 design: quasi inutile 6 design: inutile 100%

68 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -67 7/1/03 Migliorare il design l le iterazioni successive possono migliorare: n tempi di sviluppo u risorse impiegate n costi di sviluppo n qualità del prodotto n affidabilità del prodotto l le iterazioni successive possono ridurre i rischi:

69 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -68 7/1/03 Esercizio a squadre sul design l Definire mission e analisi e design e test : n progettare uno un telefonino n comprare un telefonino n progettare una radio per la macchina n organizzare una festa l valutare criticamente il lavoro altrui

70 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -69 7/1/03 Implementazione l Realizzazione del progetto di design l Per il software coincide con la codifica l Deve essere in linea con il design l Se vi sono problemi con il design, aggiornare il design e eventualmente lanalisi

71 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -70 7/1/03 Test l La fase di test serve a verificare se ho raggiunto obiettivi: l E composta da Verifica e Validazione n Verifica :stiamo costruendo un prodotto bene (implementazione soddisfa il design) u Si definiscono una serie di test per verificare che il prodotto funziona n Validazione : u stiamo costruendo il prodotto giusto ? u è efficacie ? u È 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

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

73 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -72 7/1/03 Esercizi l definire mission, analisi, design, implementazione, test per i seguenti problemi: n un videotelefono n un sistema di domotica n un dvd recorder n un ponte radio n un modem telefonico n un ristorante

74 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -73 7/1/03 Come si gestisce un progetto / problema l definire gli obiettivi del progetto l creare il piano del progetto (inizio progetto) l controllare il progetto (durante il progetto) l chiudere il progetto start pianifico Eseguo task fine monitorizzo Aggiorno piani nuovi piani Quando finisce ? controllo

75 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -74 7/1/03 Fasi per la creazione di un piano

76 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -75 7/1/03 Creare il piano del progetto l prima di iniziare un progetto si deve definire una pianificazione: l la pianificazione scompone lattività principale in sottoattività l per ogni attività n nome n responsabile n data inizio/ fine (ore uomo richieste/ disponibili) n vincoli temporali prerequisiti l i piani vengono descritti attraverso un Gannt

77 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -76 7/1/03 Esercitazione sui Gannt l I Gannt n scadenze, barre attività vincoli l Creare il Gannt di un video gioco n definire i task, risorse,... l modifiche sul Gannt n cambiare risorse n livellare n uso delle risorse n attività critiche n percorso critico

78 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -77 7/1/03 Gannt di un video gioco

79 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -78 7/1/03 Controllo l definire le misure per il controllo l misurare periodicamente l percentuale di lavoro finito l la curva di fine

80 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -79 7/1/03 controllo l definire le misure di controllo l verificare le previsioni con le misure attuali l i ritardi: strategie di recovery l curve di risposta tempo % concluso 100% fine controlli

81 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -80 7/1/03 Problemi della pianificazione/controllo l pianificazione n valutazione delle prestazioni della risorsa n disponibilità risorse n percorso critico n compatibilità con le scadenze n priorità n vincoli n forward scheduling backward scheduling

82 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -81 7/1/03 Verificare i ritardi oggi % concluso 100% Fine teorica controlli previsione Misura reale Fine reale

83 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -82 7/1/03 Esercitazioni l Definire il piano per ottenere loutput della esercitazione n definire i tempi e i controlli l il piano degli esami l il piano per la progettazione del software l il piano per la progettazione dellorganizzazione festa l il piano organizzazione vacanze l il piano start up di un ristorante l il piano di start up di un sito web l domande n quali assunzioni n quali dati di input n quali vincoli n come si controlla, quali misure n i tempi sono stati rispettati

84 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -83 7/1/03 Fasi del progetto: Harvard Business School

85 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -84 7/1/03 Obiettivi raggiunti l Da ricordare n le fasi della progettazione Mission, analisi, design, implementazione, test n cosa è la mission n la differenza fra analisi e design (cioè cosa fare e come realizzarlo) n il test l essere capaci di : n definire le fasi di progetto e il test per un generico problema n definire la pianificazione di un progetto n definire le metodologie di controllo

86 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -85 7/1/03 Lezione 4 Ciclo di vita del software gerarchie Più che una disciplina o un corpo di conoscenza, lingegneria è un modo di affrontare un problema Scott Whitmire

87 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -86 7/1/03 Modelli del processo software l Ciclo di vita di un progetto software = Modello e sequenza delle attività di sviluppo. l Tipi di modelli: n Il modello sequenziale lineare (modello a cascata o gran design) n Il modello basato sulla prototipazione n Il modello RAD (Rapid Application Development) n Modelli evolutivi – Il modello incrementale – Il modello a spirale – Il modello ad assemblaggio di componenti

88 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -87 7/1/03 Strutturazione e modellazione del sistema e dei dati (livello sistema) Analisi dei requisiti sw. ProgettazioneCodificaCollaudo Problemi: i progetti reali non si conformano allo schema sequenziale ogni modifica nello schema può causare confusioni non può essere governata lincompletezza dei requisiti versione funzionante solo verso la fine del progetto stati bloccanti per colpa della sincronizzazione tra le attività o tra i membri del team Modello a cascata: Grand design Il software è una parte di un sistema più ampio. Sono necessarie unanalisi e una progettazione di alto livello per raccogliere tutti i requisiti, da cui il software utilizza solo una parte. dominio delle informazioni, funzionalità, comportamento, prestazioni, interfacce strutture di dati, architettura del software, interfacce, algoritmi delle operazioni codice

89 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -88 7/1/03 Sviluppo evolutivo l Problema: n non cè tempo di fornire una release che copra tutti i requisiti n i requisiti sono incompleti l soluzione n sviluppo in sequenza prototipi sempre più completi n i prototipi implementano sottoinsiemi di requisiti non congelati n il cliente approva o modifica le implementazioni del prototipo l Vantaggi dello sviluppo iterativo n È pianificato e gestito n È prevedibile n Permette variazioni dei requisiti più facilmente n È basato su prototipi eseguibili evolutivi e non solo documentati n Implica il cliente nellarco dellintero processo n È guidato da rischi

90 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -89 7/1/03 Definire loutput del sistema Specificare lincremento del sistema Costruire lincremento del sistema Collaudare lincremento del sistema Rilasciare lincremento del sistema Sistema è completo? Completare il rilascio del sistema 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

91 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -90 7/1/03 Strutturazione del sistema e dei dati Analisi Proget tazione CodificaCollaudo Stadio 1 Consegna dello stadio 1 Analisi Proget tazione CodificaCollaudo Stadio 2 Consegna dello stadio 2 Analisi Proget tazione CodificaCollaudo Stadio 3 Consegna dello stadio 3 Modello incrementale Utile quando la disponibilità del personale è insufficiente a garantire limplementazione completa. Si comincia con un piccolo team. Il team accresce se laccoglienza è positiva. Implementa solo una parte dei requisiti Si partizionano i requisiti in tre stadi a seconda delle priorità

92 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -91 7/1/03 Modello a spirale Il modello abbina la natura iterativa della prototipazione e gli aspetti controllati e sistematici del modello sequenziale. Sei attività portanti (task region): Pianificazione Analisi dei rischi Strutturazione Costruzione e rilascio Comunicazioni con il cliente Valutazione da parte del cliente Asse dei punti di entrata Progetti di sviluppo di nuove idee Progetti di sviluppo di un nuovo prodotto Progetti di miglioramento di un prodotto Progetti di manutenzione di un prodotto

93 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -92 7/1/03 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 Modello ad assemblaggio di componenti

94 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -93 7/1/03 modello di sviluppo RAD l consentono un tempo di sviluppo molto ridotto l il modello di sviluppo è : n analisi u Business modelling: definizione dei flussi informativi e dei processi – Data modelling – process modelling n design / implementation u application generation: direttamente con il tool di 4g. Molto del codice è già implementato nel tool n testing u limitato perchè la maggior parte del software è già sviluppato

95 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -94 7/1/03 Pro&contro del modello RAD l Pro n velocità n affidabilità (il codice è per la maggior parte già sviluppato) l contro n adatto solo se esiste un tool RAD che implementa la maggior parte del codice per lapplicazione specifica n non è facile particolareggiare il codice n non è facile migliorare le performances n spesso si ignorano i passi fondamentali della progettazione e quindi il risultato è disastroso

96 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -95 7/1/03 Riuso o sviluppo ex novo ? l Spesso sono disponibili componenti utili per lo sviluppo: debbono essere utilizzati ? lavoro da effettuare in creazione o modifica costo riuso Sviluppo ex novo

97 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -96 7/1/03 Riuso o sviluppo ex novo ? l Riduzione del ciclo di vita del software: come è ripartito fra le varie fasi ?

98 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -97 7/1/03 Analisi del costo di sviluppo l le fasi di debugging/ maintainance hanno il costo maggiore l Occorre impostare Analisi, design e codifica nel progetto in modo da minimizzare il costo di debugging testing e manutenzione

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

100 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza -99 7/1/03 Lezione 4 Seconda parte: gerarchie

101 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Regola fondamentale: Divide et Impera ! l Cosa avevano capito i Romani l La mente umana è molto limitata n il caso di Paolo d. (problema finanziario) /alessia M(psicologia nei problemi complessi) Problema Problema affrontabile

102 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Implicazioni del divide et impera l divido il problema in sottoproblemi risolvibili l risolvo un sottoproblema alla volta considerando gli altri risolti l definire sottoproblemi mi aiuta a dividere il lavoro fra più persone Problema dato per risolto Problema da affrontare

103 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Dal sistema al dettaglio:gerarchie e zoom Divide et Impera ! l Se il sistema è troppo complesso: n 1) si definisce lanalisi del sistema (gerarchia uno) n 2) si definiscono i sottosistemi (gerarchia due) n 3) si definiscono le interfacce n 4) si procede sul sottosistema come se fosse un sistema u mission, analisi, design,.... l Se i sottosistemi sono ancora troppo complessi n si crea una altra gerarchia

104 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Gerarchie l Dato un sistema connesso con lesterno da interfacce esterne, una gerarchia è composta da: n sottosistemi che partizionano il sistema n interfacce che connettono i sottosistemi n le interfacce esterne che connettono i sottosistemi con il mondo esterno sistema Mondo Interfaccia 1 sottosist Interfaccia 2 Interfaccia 1 Interfaccia 3Interfaccia 4 sottosist Gerarchia 3 Gerarchia 2

105 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Come si definiscono i moduli? l Principio di massima coesione e minimo accoppiamento n un modulo deve essere: u internamente massimamente coeso – deve offrire un servizio completo u minimamente accoppiato con gli altri moduli – le interfacce devono essere di minima consistenza – i moduli sono minimamente interdipendenti

106 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Coesione ed accoppiamento Spettro della coesioneBassaAlta DispersivoConcentrato Casuale Logica Temporale Procedurale Di comunicazione Sequenziale Funzionale Spettro dellaccoppiamentoBassaAlta Nessun accoppiamento diretto Accoppiamento di dati Accoppiamento a template Accoppiamento di controllo Accoppiamento esterno Accoppiamento comune Accoppiamento di contenuto

107 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Esempio di definizione dei moduli l definire un design corretto e scorretto di modularizzazione

108 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Determinazione del numero dei moduli l Quanti moduli devo fare n il costo di un sistema è proporzionale alla complessità n la complessità è data dalla somma della complessità intramodulo e della complessità delle interfacce intermoduli Complessità & costo Maggiore Granularità (+ moduli +piccoli) Complessità totale Complessità delle interfacce= costo di integrazione Complessità dei modulo = costo per modulo

109 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Esempio: progettazione di una auto l auto troppo complessa! Divide et impera ! n Definisco la mission u progettare una auto utilitaria per lItalia n 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 n definisco i sottosistemi (gerarchia di primo livello) u motore, carrozzeria, ruote,freni, volante, cambio n definisco le interfacce fra i sottosistemi

110 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Esempio auto gerarchia primo livello l Motore n Mission: muovere la macchina u R_auto_1: deve raggiungere la velocità di almeno 140 – R_Moto_1: deve avere 6000 giri con 4KW potenza u R_auto_2: deve lavorare fra -15° e +45° – R_Moto_2: non deve congelare sotto i 15°... l Il motore come sistema è ancora troppo complesso-> espandiamo la gerarchia: n motore composto da : – refrigerazione, – propulsione – centralina di controllo

111 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 La gerarchia del progetto auto l La struttura è simile ad WBS (work breakdown structure) l legami con OBS (organization) e CBS (cost) l Quali sono le interfacce ? u esercizio

112 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Regole per la costruzione della gerarchia l le interfacce definiscono i rapporti fra due sottosistemi l le interfacce devono essere coerenti fra diverse gerarchie l tutti i requisiti di un sistema si devono tradurre in requisiti per i sottosistemi l lo zoom fra le varie gerarchie deve essere coerente a livello di interfacce e di contenuti

113 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Coerenza delle gerarchie per le interfacce l gerarchia 1 n contenuto Lazio n interfacce esterne: A1 Napoli, A1 Firenze n gerarchia 2 province del Lazio (Roma LT, FR, VT, RI) u interfacce esterne: A1 Napoli (LT), A1 Firenze (FR) u interfacce interne: RM LT (Pontina,...), RM VT (Cassia,...) u gerarchia 3 comuni di Latina (Formia, Gaeta,... LT, FR, VT, RI) l non si devono perdere le interfacce

114 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Gli attori l gli attori sono tutte le entità che interagiscono con il sistema l gli attori sono collegati con il sistema attraverso interfacce esterne u gli attori non sono solo persone l per il sottosistema motore gli attori sono: n cambio(interfaccia albero di trasmissione) n comandi utente (interfaccia filo acceleratore)

115 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 diagramma funzionale con attori comanda Auto guidatorestrada interagisce Gerarchia 1° livello comanda Comandi auto strada interagisce Gerarchia 2° livello Motore Ruotefreni guidatore cambio

116 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 diagramma funzionale: 3° gerarchia gestisce Motore Comandi auto cambio Invia rotazione Gerarchia 3° livello strada interagisce Ruote Freni bloccano girano Invia rotazione Comandi auto cambio

117 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 diagramma funzionale: 4° gerarchia gestisce Motore Invia rotazione Gerarchia 3° livello controllo propulsore refrigeramento Gerarchia 4° livello cambio Comandi auto gestisce Comandi auto cambio Invia rotazione

118 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Requisiti di interfaccia l Gerarchia 1: interfacce esterne u comanda, interagisce: l Gerarchia 2: interfacce interne u girano, bloccano, invia rotazione l Gerarchia 3: interfacce interne u.... l Le interfacce di una gerarchia vengono ereditate e eventualmente approfondite nelle gerarchie successive

119 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Esercizio: il ristorante l definire mission l analisi di sistema n requisiti del sistema n attori n interfacce esterne e requisiti associati l definire i sottosistemi (gerarchia di primo ordine) n definire interfacce interne fra sottosistemi e requisiti associati n associare interfacce esterne a sottosistemi n analisi di sottosistema u requisiti del sottosistema

120 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Esercitazione: sistema gestione ordini e conto per ristoranti l mission: progettare un sistema informatico che gestisca gli ordini e il conto finale per ogni ristorante n analisi di sistema u requisiti del sistema u attori u interfacce esterne e requisiti associati n definire i sottosistemi (gerarchia di primo ordine) u definire interfacce interne fra sottosistemi e requisiti associati u associare interfacce esterne a sottosistemi u analisi di sottosistema – requisiti del sottosistema

121 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Obiettivi raggiunti l saper scegliere il giusto modello di sviluppo in base alla tipologia di problema modello a cascata, evolutivo, incrementale, a spirale, assemblaggio di componenti, RAD l per ogni problema essere capaci di : n individuare sottoproblemi (gerarchia 1) u determinare i sottosistemi in base alla complessità di interfaccia e di modulo u definire interfacce esterne e interne u associare e definire i sottorequisiti n iterare il processo per il numero di gerarchie necessarie

122 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Lezione 5 Strumenti per lanalisi: diagrammi E/R, Use case, diagrammi di Eventi

123 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Mission Analisi Design Implement. Test Le fasi della progettazione

124 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Attività di analisi l 1: Comprensione del problema: Requisiti. l 2: utilizzo del sistema dal punto di vista utente: n casi duso. l 3: Modellazione. l 4: Specifica l 5: Riesame.

125 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Attività di analisi : 1 l 1: Comprensione del problema: Requisiti. n Per mezzo di interazioni e discussioni con lutente e dello studio della specifica del sistema e del piano di progetto (se ci sono!), lanalista raccoglie i requisiti. Requisiti: descrizione di come il cliente o lutente desidera essere il sistema. n Gli elementi acquisiti dallanalista sono : u una descrizione del sistema u gli attori del sistema u gli obiettivi del sistema u le funzioni del sistema u gli attributi del sistema l 2: utilizzo del sistema dal punto di vista utente: casi duso. n Per chiarire a sè e allutente il sistema da progettare, lanalista descrive come il sistema verrà utilizzato dallutente attraverso i casi duso. I casi duso sono scenari che mostrano lutilizzo del sistema in situazioni specifiche

126 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Attività di analisi : 2 l 3: Modellazione. Lanalista 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 loperatività del sistema. l 4: Specifica. Requisiti, gerarchie, casi duso, modelli E/R, funzionali e di stato vengono riorganizzati e ingegnerizzati. l 5: Riesame. Verifica della completezza, consistenza e accuratezza della specifica.

127 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Strumenti di analisi l 1: Comprensione del problema n Requisiti l 2: utilizzo del sistema dal punto di vista utente n casi duso l 3 Modellazione n gerarchie n modelli dei dati (E/R) n modelli funzionali n diagrammi di stato n diagrammi di interazione (eventi) l 4: Specifica. n ingegnerizzazione dei requisiti e modelli l 5 Riesame

128 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Modello dei dati l Descrive il mondo dei dati del problema dal punto di vista dellanalisi l elementi di un modello di dati: n oggetti u attributi:sono i dati di un oggetto (=descrivono caratteristiche oggetto e riferimenti ad altri oggetti) n Relazioni: definiscono i collegamenti fra oggetti (approfondite quando si parlerà di OO) u cardinalità: numero di occorrenze di oggetti in una data relazione

129 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Diagrammi E/R (notazione UML) Oggetto attributo 1 (ID) attributo 2.. Oggetto attributo 1 (ID) attributo n CardinalitàRelazione * Nome relazione

130 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 sistema gestione ordini e conto per ristoranti (GOCR):gerarchia 1° l mission: progettare un sistema informatico che gestisca gli ordini e il conto finale per ogni ristorante Sistema Gocr cucinaCameriere Cliente Gestore approvvigionamenticassa Stampa conto Ordini/ conti Ordini pietanze Analisi scorte

131 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 GOCR gerarchia 2° (struttura dati) Ordine ID ID Tavolo Ora gestito da Cameriere ID Nome Quantità richiesta ID Pietanza ID ingrediente quantità ingrediente ID quantità disponibile Tavolo ID stato Pietanza ID tipo Prezzo Singolo ord. ID ordine id pietanza quantità l conoscete MS Access ?

132 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Modello in Access

133 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Diagrammi E/R l Criteri per la progettazione n Eliminazione dei percorsi ciclici n Eliminare la ridondanza dei dati /relazioni n Cercare la max semplicità u Minimo numero di records e di relazioni per il problema in esame n Non confondere E/R (senza info di tempo ) con lordine di inserimento dei dati nel database n Navigare le relazioni per valutare coerenza n Valuare i costi di scelta attributo o relazione ? n NO colonne variabili !!!

134 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 GOCR gerarchia 2° (struttura funzionale) cucinaCameriereGestore scortecassa Gestione conti Gestione ordini Calcolo conti Preparazione pietanze Gestione scorte conti

135 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Diagramma di stato (stato tavoli) : esercitazione l Convenzione UML l Esercizio: n identificare stati u libero,attesa ordine, in_consumazione,richiesta conto n identificare transazioni start stato transizione

136 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 esercizio: segreteria telefonica l Identificare gli stati e le conessioni

137 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Use cases: Attori Cliente di banca Operatore Bancomat Sistema informatico bancario BANCOMAT Qualunque entità esterna interagisce con il sistema, persone o macchine, può essere modellizzato come un attore. Analizzando gli attori ci concentriamo su come il sistema sarà utilizzato e non su come sarà progettato o implementato. StudenteProfessoreSistema paghe OperatoreGestore Utente sistema attore generalizzazione

138 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Casi duso (use cases) l Specifica di un comportamento di un sistema n Un caso duso è una modo per utilizzare un sistema, o anche uno schema del suo comportamento. n 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. n I casi duso non contengono informazioni su come realizzare il comportamento. n Un caso duso descrive uninsieme di sequenze, in cui ciascun sequenza rappresenta linterazione di entità esterne al sistema (attori) con il sistema.. n Un caso duso rappresenta un requisito funzionale dellintero sistema. l É il contenuto base del manuale utente

139 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Casi duso Prelevamento Cliente della banca Casi duso e attori: Ciascun caso duso può coinvolgere più attori. Un attore può utilizzare più casi duso dello stesso sistema. Per ciascun attore, si deve identificare come vuole utilizzare il sistema. Ciascun modo di utilizzare il sistema diventa un caso duso. Gestione Corso Gestione Piano CorsiCircoscrizione::Richiesta di certificato semplice nome nome con percorso Sistema Fuori sistema

140 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Come scrivere un caso duso 1. Viene creato un documento di flusso di eventi per ciascun caso duso. Il documento è scritto dal punto di vista di un attore. 2. Viene dettagliato che cosa il sistema deve rilasciare allattore quando il caso duso viene eseguito. Tipicamente il documento contiene: n Come inizia e come si termina il caso duso n Il flusso normale di eventi n I flussi alternativi di eventi n I flussi straordinari di eventi Caso duso Nome: Attori: Precondizioni: Postcondizioni: Descrizione: Eccezioni:

141 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Descrizione di un caso duso Caso duso: 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 duso descrive un insieme di sequenze di eventi che sono varianti nello stesso caso. Ciascuna sequenza rappresenta uno scenario. Uno scenario è rispetto ad un caso duso come unistanza rispetto alla classe.

142 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Caso duso: telefonata con il telefonino l lutente spinge i bottoni del numero di telefono richiesto l lutente aspetta un segnale l se libero aspetta Caso duso Nome:telefonata con tel Attori:utente Precondizioni:acceso Postcondizioni: Descrizione: Eccezioni:

143 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Professore Richiesta Corso Studente Gestione Piano di Studi Sistema di tasse Operatore Gestione Piano Semestrale Diagrammi di casi duso I diagrammi di casi duso 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.

144 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Identificazione dei casi duso 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 lutente parla come fossero variazioni su una unica tema. 5. Denominare i casi duso e fornire una descrizione. 6. Cercare i frammenti comuni tra i differenti casi duso e fattorizzarli in casi duso di base e aggiunti. 7. Associare ad ogni caso duso un valore di priorità.

145 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Diagramma di eventi l I diagrammi di interazioni descrivono come vengono realizzati i casi di uso attraverso le interazioni tra oggetti. l Contiene uninsieme di messaggi interscambiati tra un insieme di oggetti in un certo ambiente (sistema, sottosistema ecc.) per compiere un certo obiettivo. l Quando due oggetti sono connessi tra loro, cè un caso dinterazione. l Un diagramma di sequenze di eventi mostra uninterazione disposta in ordine cronologico. Mostra gli oggetti partecipanti allinterazione con le loro linee di vita e i messaggi scambiati in ordine cronologico. l Messaggio - specifica di una comunicazione tra oggetti, trasporta uninformazione con lintento di far scattare unattività

146 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Diagrammi di sequenze (=di eventi) Tempo utente telefonino Digita numero risponde a b c {b-a<2sec} Oggetto Linea della vita delloggetto rappresenta lesistenza delloggetto o dellattore Messaggio - call - return - send - create - destroy {b-a<5sec} Attivazione Mostra il periodo in cui un oggetto realizza unazione etichetta b Vincolo Tempo della transizione chiamata Risposta libera interlocutore Voce inter.

147 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 sistema gestione ordini e conto l mission: progettare un sistema informatico che gestisca gli ordini e il conto finale per ogni ristorante l definire diagramma eventi per ordini e conto finale Sistema Gocr cucinaCameriere Cliente Gestore approvvigionamenticassa Stampa conto Ordini/ conti Ordini pietanze Analisi scorte

148 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Esercizio diagramma di sequenza per GOCR Cameriere Sistema Gocr cassacucina

149 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Esercizio: organizzo una vacanza IO amici agenzia Tour operator

150 Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza /1/03 Obiettivi raggiunti l Da ricordare n gli strumenti a disposizione dellanalisi l Per qualsiasi problema essere capaci di : n individuare gli strumenti di analisi necessari u E/R, Use case diagramma di eventi, diagramma funzionale, diagrammi di stato n individuare quali strumenti non sono necessari n saper modellare la struttura dati (E/R) n saper definire gli stati interni se necessario (diag. di stato) n saper creare un caso duso n saper descrivere una interfaccia con gli strumenti di analisi


Scaricare ppt "Copyright Prof. Claudio Becchetti, Università di Roma La Sapienza 7/1/03 Progettazione di Apparati e Sistemi di TLC Prof. Claudio Becchetti Laboratorio."

Presentazioni simili


Annunci Google