AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi"

Transcript

1 AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato Unified Process (UP) è il processo di ingegneria del software diventato standard industriale Definisce il chi, il cosa, il quando e il come dello sviluppo del software UP definisce un modello generale di processo da cui si sono sviluppate diverse varianti Rational Unified Process (RUP) è sicuramente la variante più conosciuta 2 Page 1

2 Nascita di UP 1967 Presso Ericsson si pongono le basi del Component-Based Development Un sistema complesso è visto come un insieme di blocchi interconnessi 1976 CCITT rilascia il Specification and Description Language Linguaggio per sistemi di telecomunicazione dove i sistemi sono modellati come un insieme di componenti che si scambiano segnali 1987 Jacobson fonda Objectory AB che mette sul mercato un processo di ingegneria del software: Objectory (Object Factory) Il processo è basato su un set di documentazione standard e uno strumento CASE 1995 Rational Rose acquisisce Objectory AB 1997 UML diventa standard OMG 1999 nasce UP 3 UP e UML UML inizialmente doveva fornire sia un linguaggio visuale che il processo di ingegneria del software Ad oggi UML fornisce solo il linguaggio visuale UP fornisce il processo di ingegneria del software che utilizza come linguaggio visuale UML 4 Page 2

3 UP come Processo Generico UP è un processo di sviluppo del software generico e deve essere istanziato per ogni organizzazione e progetto Il processo di istanziazione deve definire e integrare: Gruppo di lavoro Modelli di documento Strumenti: compilatori, gestione delle configurazioni, Archiviazione: gestione bug, gestione del progetto Ciclo di vita 5 Assiomi di UP UP è basato su tre assiomi fondamentali: È pilotato dai casi di uso e dai fattori di rischio È importante individuare il prima possibile gli eventuali rischi che si possono dover affrontare nel processo di sviluppo e predisporre le modalità con cui possano essere superati È incentrato sull architettura L architettura di un sistema descrive gli aspetti strategici di un sistema (come è scomposto in componenti, come questi componenti interagiscono, etc.) Quindi una buona architettura è la base di un buon sistema È iterativo e incrementale Il progetto viene scomposto in sottoprogetti (iterazioni) ognuno dei quali porterà al rilascio di alcune nuove funzionalità 6 Page 3

4 Iterazioni Ogni iterazione contiene tutte le attività tipiche di un processo di sviluppo di ingegneria del software: Pianificazione Analisi e progettazione Costruzione Integrazione e test Rilascio Ogni iterazione porta al raggiungimento di una baseline corrispondente a una versione parzialmente completa del sistema finale e la relativa documentazione La differenza tra due baseline consecutive viene detta incremento 7 Iterazioni Ogni iterazione si basa principalmente su cinque flussi di lavoro che devono essere eseguiti in cascata: Raccolta dei requisiti (Requirements) Elenca le funzionalità che il sistema dovrebbe avere Analisi (Analysis) Completa e raffina le funzionalità elencate nella fase di raccolta dei requisiti e definisce un modello del sistema (modello di analisi) concentrato sulle funzionalità Progettazione (Design) Progetta un architettura e le differenti componenti che realizzano le funzionalità definite nella fase di analisi Implementazione (Implementation) Realizza il sistema definito dalla fase di progettazione Test (Test) Verifica il corretto funzionamento e il soddisfacimento dei requisiti 8 Page 4

5 Modelli UML e Flussi di Lavoro Ogni tipo di flusso di lavoro si basa su alcune classi di modelli (diagrammi) UML: Raccolta dei requisiti (Requirements) Use Case Model (Use Case, Sequence, Statechart, Activity) Analisi (Analysis) Analysis Model (Class, Sequence, Collaboration, Statechart, Activity) Progettazione (Design) Design Model (Class, Sequence, Collaboration, Statechart, Activity) Deployment Model (Deployment, Sequence, Collaboration) Implementazione (Implementation) Implementation Model (Component, Sequence, Collaboration) Test (Test) Test Model 9 Fasi di UP Inception Elaboration Construction Transition Il ciclo di vita di un progetto è diviso in quattro fasi in cascata Ogni fase si conclude con un importante milestone: Obiettivi (Vision) Architettura (Baseline architecture) Capacità operativa iniziale (Initial capability) Rilascio del prodotto (Product release) 10 Page 5

6 Fasi e Flussi di Lavoro La quantità di lavoro richiesto per ciascuno dei cinque flussi di lavoro fondamentali varia nelle diverse fasi del progetto 11 Fasi e Iterazioni Una fase può comprendere più iterazioni; in particolare, per le fasi di Elaborazione e Costruzione 12 Page 6

7 Avvio Questa fase ha l obiettivo di far decollare il progetto attraverso: Studio di fattibilità Generazione di un caso di business (business case) Definizione dei requisiti essenziali Identificazione dei rischi più critici Questa fase si basa quasi completamente sulle attività relative alla raccolta dei requisiti e all analisi Attività di progettazione e di implementazione potrebbero essere richieste se si rendesse necessaria la realizzazione di un prototipo o di alcune prove di fattibilità 13 Avvio Milestone di questa fase è la definizione degli obiettivi del progetto A questa milestone corrisponderà il rilascio di alcuni artefatti: Documento di alto livello con i principali requisiti, caratteristiche e vincoli del progetto Modello dei casi di uso iniziale (completo al 10-20%) Glossario del progetto (elenco dei principali requisiti) Caso di business Prima pianificazione del progetto (costi e tempi) Documento di valutazione dei rischi Uno o più prototipi Documento iniziale sull architettura del sistema 14 Page 7

8 Ingegneria dei Requisiti L ingegneria dei requisiti è la disciplina che si occupa di: Raccogliere e tenere aggiornato l insieme dei requisiti Assegnare le priorità ai diversi requisiti Documentare i diversi requisiti È un processo di negoziazione che cerca di raggiungere un buon compromesso per tenere conto delle diverse esigenze del sistema L ingegneria dei requisiti ha una grande importanza nel processo di sviluppo del software La prima causa di fallimento dei progetti software è il mancato successo delle attività di ingegneria dei requisiti La seconda causa di fallimento dei progetti software è la mancanza di coinvolgimento dei futuri utenti 15 Requisiti Funzionali e Non Funzionali L ingegneria dei requisiti dovrebbe trattare due tipi diversi di requisiti: Requisiti funzionali, cioè cosa deve fare il sistema Requisiti non funzionali, cioè i vincoli che il sistema deve rispettare (prestazioni, affidabilità, etc.) In teoria, i requisiti dovrebbero indicare esclusivamente cosa un sistema deve fare e non il come lo deve fare Tuttavia, possono esistere dei vincoli sul comportamento del sistema che, almeno in parte, predeterminano, il come 16 Page 8

9 Attività dell Ingegneria dei Requisiti Le attività coinvolte nella raccolta dei requisiti sono le seguenti: Individuare i requisiti funzionali Individuare i requisiti non funzionali Assegnare le priorità ai requisiti Estrarre i casi d uso dai requisiti Descrivere i casi d uso Strutturare il modello dei casi d uso 17 Formulazione dei Requisiti I requisiti possono essere specificati in differenti modi: Frasi in linguaggio naturale Strumenti di ingegneria dei requisiti L insieme di specifiche generato viene comunemente indicato con il nome di Specifiche dei Requisiti di Sistema (SRS) UML non fornisce alcuna indicazione su come scrivere una SRS Un formato molto semplice, ma efficace è identificare ogni requisito nel seguente formato: <id> <sistema> dovrà <funzione> dove: <id> è un identificatore univoco <sistema> identifica il sistema <funzione> identifica la funzione richiesta al sistema 18 Page 9

10 Esempio di Formulazione dei Requisiti SRS per uno sportello automatico tipo bancomat Requisiti funzionali RF1: il sistema dovrà controllare la validità della tessera inserita RF2: il sistema dovrà controllare la validità del PIN digitato dal cliente RF3: il sistema dovrà erogare non più di 500 per carta nell arco di 24 ore RF4: il sistema dovrà erogare non meno di 10 per operazione RF5: il sistema dovrà essere sempre attivo Requisiti non funzionali RNF1: il sistema dovrà comunicare con la banca tramite un codice cifrato a 256 bit RNF2: il sistema dovrà controllare la validità della tessera inserita entro 3 secondi RNF3: il sistema dovrà controllare la validità del PIN digitato dal cliente entro 3 secondi 19 Filtro dei Requisiti Se i requisiti di un SRS sono formulati in linguaggio naturale, allora possono essere raffinati attraverso una tecnica propria dell analisi del linguaggio naturale: La grammatica delle trasformazioni I requisiti possono essere raffinati attraverso tre filtri: Rimozione RF4: il sistema dovrà essere sempre attivo Distorsione RF3: il sistema dovrà erogare non più di 500 per carta nell arco di 24 ore RF3: il sistema dovrà erogare non più di un certo valore per carta nell arco di 24 ore in base al tipo di carta Generalizzazione RF4: il sistema dovrà erogare non meno di 10 per operazione RF4: il sistema dovrà erogare non meno di un certo valore per operazione 20 Page 10

11 Mappatura dei Requisiti L operazione di mappatura dei requisiti permette di individuare i requisiti che non sono coperti da nessun caso di uso Questa operazione mette in relazione i requisiti funzionali contenuti nel SRS e i casi di uso Questa operazione ha lo scopo di individuare: La presenza di requisiti non coperti da casi di uso La mancanza di requisiti RF1 RF2 RF3 RF4 UC1 X UC2 X UC3 X X UC4 X UC5 RF5 RF6 X 21 Glossario del Progetto Il glossario del progetto è il dizionario che: Contiene i principali termini del dominio e la loro definizione Risolve i casi di sinonimia e omonimia: Ad ogni termini viene associata una lista di sinonimi Viene scelto un unico significato per il termini e se possibile vengono introdotti altri termini per gestire gli altri significati UML non fornisce alcun standard per questo glossario Un formato molto semplice, ma efficace è quello di un dizionario: Elenco di vocaboli ordinati alfabeticamente Ad ogni vocabolo è associata una definizione e una lista di sinonimi È molto importante che gli stessi vocaboli e definizioni vengano usati in tutti i documenti del processo di ingegneria del software 22 Page 11

12 Elaborazione Questa fase ha i seguenti obiettivi: Creare una baseline eseguibile Perfezionare la valutazione dei rischi Definire gli attributi di qualità (velocità di individuazione dei difetti, densità massima di difetti accettabili, etc.) Fissare i casi d uso relativi ad almeno l 80% dei requisiti funzionali del sistema da realizzare Creare un piano dettagliato della fase di costruzione Formulare una valutazione iniziale delle risorse, tempo, strumenti, persone e costi richiesti nella realizzazione del sistema La baseline eseguibile non sarà un prototipo, ma piuttosto una prima approssimazione del sistema obiettivo del progetto su cui si appoggeranno le baseline realizzate dalle fasi successive 23 Elaborazione Questa fase si basa su tutti i cinque flussi di lavoro fondamentali e ognuno di essi ha degli obiettivi ben definiti Raccolta dei requisiti Fissare la maggioranza dei requisiti Raffinare l ambito del sistema Analisi Definire ciò che deve essere costruito Progettazione Definire un architettura stabile Implementazione Costruire una baseline eseguibile Test Testare la baseline Le attività relative alla raccolta, analisi e progettazione hanno il maggior peso, tuttavia, verso la fine della fase di Elaborazione, l implementazione inizia ad assumere un peso maggioritario 24 Page 12

13 Elaborazione Milestone di questa fase è la definizione dell architettura del sistema A questa milestone corrisponderà il rilascio di alcuni artefatti: Baseline eseguibile Modello dei casi di uso UML, Modello statico e dinamico UML Documentazione descrittiva del sistema Pianificazione del progetto aggiornata (opzionale) Caso di business aggiornato (opzionale) Documento di valutazione dei rischi aggiornato (opzionale) Accordo firmato 25 Flusso di Lavoro dell Analisi Il flusso di lavoro di analisi ha l obiettivo di produrre un modello di analisi Si concentra su che cosa il sistema deve fare Il dettaglio del come farlo è compito del flusso di lavoro di progettazione Il modello di analisi è basato su una collezione di diagrammi e di elementi di modellazione, in particolare, su due artefatti: Classi di analisi: modellano i concetti chiave del dominio del problema Casi di uso: mostrano come le istanze delle classi di analisi possono interagire per realizzare il comportamento del sistema 26 Page 13

14 Modello di Analisi Il modello di analisi si dovrebbe basare esclusivamente su quelle classi che fanno parte del vocabolario del dominio del problema (il Glossario) Bisogna evitare di introdurre delle classi di progettazione (classi per l accesso alla rete o a database, a meno che ) L obiettivo è fornire una rappresentazione semplice e concisa della struttura e del comportamento del sistema Tutte le decisioni implementative devono essere lasciate ai flussi di lavoro della progettazione e implementazione 27 Modello di Analisi Si possono indicare alcune regole pratiche ed efficaci per la modellazione dell analisi: Esprimere il modello dell analisi nel linguaggio del problema (uso del Glossario) Creare modelli che raccontano una storia (uso dei casi di uso) Concentrare l attenzione sulle viste di insieme (disuso dei dettagli) Mantenere una netta distinzione tra il dominio del problema (requisiti del business) e il dominio delle soluzioni (dettagli di progettazione) Concentrare l attenzione sulle astrazioni del dominio applicativo (uso di classi corrispondenti a entità del business e disuso di classi corrispondenti a soluzioni implementative) Limitare le interdipendenze tra le classi di analisi (uso appropriato delle relazioni di ereditarietà, molteplicità e navigabilità) Fornire modelli utili a tutte le parti (committenti, progettisti e sviluppatori) Mantenere semplice il modello (uso di ereditarietà e polimorfismo) 28 Page 14

15 Individuazione delle Classi di Analisi Non esiste un algoritmo che permette di individuare le classi di analisi, se esistesse, questo algoritmo sarebbe un metodo infallibile per progettare il software Tuttavia esistono delle tecniche che sono state provate e sperimentate per trovare delle buone soluzioni Queste tecniche si basano sull analisi del testo e sulle interviste agli utenti e agli esperti del dominio Due tecniche molto utilizzate sono: L analisi nome/verbo L analisi classe, responsabilità e collaboratori (CRC) Spesso più di una tecnica viene utilizzata e le classi vengono individuate dal confronto dei risultati delle varie tecniche di analisi 29 Analisi Nome/Verbo L analisi nome/verbo è un modo molto semplice per estrarre le classi dai documenti forniti dal flusso di lavoro di raccolta dei requisiti: I nomi e le frasi nominali rappresentano le classi e gli attributi I verbi e le frasi verbali le responsabilità e le operazioni delle classi I problemi più ricorrenti sono: Trattare i casi di sinonimia e omonimia Individuare le classi nascoste cioè le classi implicite del dominio del problema che possono anche non essere mai menzionate esplicitamente Ad esempio, in un sistema di prenotazione di una compagnia di viaggi si potrebbe parlare di prenotazione, richiesta, ma tralasciare il termine ordine 30 Page 15

16 Analisi Nome/Verbo I passi dell analisi nome/verbo sono i seguenti: Raccolta delle fonti di informazione SRS (se esiste) Casi di uso Glossario di progetto Altri documenti esistenti (architettura, visione aziendale, ) Estrazione degli elementi di analisi dei documenti I nomi I predicati nominali (ad esempio, numero del volo) I verbi I predicati verbali (ad esempio, verificare la carta di credito) Definizione delle classi di analisi Individuazione delle classi Assegnazione di attributi e responsabilità alle classi Individuazione di relazioni tra le classi 31 Analisi CRC L analisi classe, responsabilità e collaboratori (CRC) è un modo efficiente di coinvolgere gli utenti nella ricerca delle classi Questa tecnica si basa sull uso di comuni foglietti nota adesivi (in genere di colore giallo): I foglietti vengono suddivisi in tre aree per contenere Il nome della classe Le responsabilità I collaboratori I foglietti vengono appiccicati ad un muro o a una lavagna Se viene usata la lavagna, per evidenziare le relazioni possono venire tracciate delle linee tra le classi che collaborano 32 Page 16

17 Analisi CRC I passi dell analisi CRC sono raggruppati in due fasi: Brainstorming per raccogliere l informazione Spiegazione ai partecipanti che si tratta di un brainstorming Tutte le idee sono considerate buone e registrate La discussione e l analisi verrà effettuata successivamente Richiesta ai partecipanti di nomi di cose che agiscono nel dominio del problema Ogni cosa viene scritta su un foglietto diverso Ogni foglietto viene appiccicato ad una parete o a una lavagna Richiesta ai partecipanti di indicare le responsabilità che quelle cose potrebbero avere Individuazione assieme ai partecipanti delle classi che potrebbero lavorare insieme Analisi dell informazione Individuazione di classi e attributi 33 Costruzione Questa fase ha i seguenti obiettivi: Completare la raccolta dei requisiti, l analisi e la progettazione Far evolvere la baseline eseguibile realizzata nella fase di Elaborazione nella versione finale Vincolo molto importante in questa fase è il mantenimento dell integrità dell architettura del sistema 34 Page 17

18 Costruzione Questa fase si basa su tutti i cinque flussi di lavoro fondamentali e ognuno di essi ha un obiettivo ben definito Raccolta dei requisiti Completare la lista dei requisiti Analisi Completare il modello di analisi Progettazione Completare il modello di progettazione Implementazione Test Costruire la cosiddetta capacità operativa iniziale Testare la capacità operativa iniziale In questa fase le attività di implementazione sono le più importanti, ma anche il test ha una sua importanza: Ad ogni incremento bisogna eseguire gli unit test e i test di integrazione 35 Costruzione Milestone di questa fase è la realizzazione della cosiddetta capacità operativa iniziale cioè di un sistema software finito su cui gli utenti possano eseguire il beta test A questa milestone corrisponderà al rilascio di alcuni artefatti: Prodotto software Modelli UML Test suite Manuale utente Descrizione di rilascio Pianificazione del progetto (confronto tra costi reali e previsti) 36 Page 18

19 Flusso di Lavoro della Progettazione Il flusso di lavoro di progettazione ha l obiettivo di definire in modo completo come le funzionalità definite nella fase di analisi debbano essere implementate La progettazione comporta lo studio e l integrazione delle soluzioni tecniche (librerie software, meccanismi di persistenza, ), che appartengono al dominio delle soluzioni, per la messa a punto di un modello del sistema (modello di progettazione) che possa essere effettivamente implementato 37 Modello di Progettazione Il modello di progettazione si basa sul modello di analisi e può essere considerato una sua evoluzione o elaborazione Il modello di progettazione utilizza principalmente due termini: Sottosistema Interfaccia L attività di progettazione si concentra nell individuazione e modellazione delle interfacce principali 38 Page 19

20 Modello di Progettazione Il modello di progettazione è composto da cinque tipi di artefatti: Sottosistemi di progettazione Classi di progettazione Interfacce Realizzazione di casi di uso Diagramma di deployment 39 Modello di Progettazione Classi, interfacce e casi di uso derivano dal modello di analisi: Una classe di analisi in genere rappresenta una rappresentazione concettuale, di alto livello delle classi del sistema Può richiedere più di una classe e/o interfaccia di progettazione 40 Page 20

21 Classi di Progettazione Le classi di progettazione sono classi le cui specifiche sono così complete che possono essere effettivamente implementate Le classi di progettazione hanno due origini: Il dominio del problema La classe viene definita attraverso un processo di rifinitura delle classi di analisi Esiste una relazione «origine» tra una classe di analisi e la classe o le classi di progettazione Il dominio delle soluzioni Il dominio delle soluzioni contiene Librerie di utilità e di componenti riutilizzabili (classi per gestire tipi comuni, classi contenitori, ) Middleware (comunicazione, persistenza dei dati, ) Framework di componenti (CORBA, DCOM, EJB, ) 41 Classi di Progettazione Durante l analisi si cerca di fissare il comportamento richiesto al sistema senza preoccuparsi di come sarà realizzato La progettazione deve specificare esattamente come le classi del sistema assolveranno le loro responsabilità Per raggiungere questo obiettivo è necessario per ogni classe: Completare l insieme degli attributi e specificare completamente ogni attributo (nome, tipo, ) Ricavare dalle operazioni definite durante l analisi l insieme completo dei metodi 42 Page 21

22 Transizione Questa fase ha come principali obiettivi: Sistemazione dei difetti scoperti nel beta test del sistema Preparazione del rilascio a tutti gli utenti Questi due obiettivi possono essere dettagliati nella seguente lista di obiettivi: Correggere i difetti Modificare il software nel caso in cui sorgessero dei problemi non previsti Preparare i siti utente per il nuovo software Adattare il software in modo da operare correttamente presso i siti utente Aggiornare il manuali utente e create eventuale altra documentazione Fornire consulenti agli utenti Eseguire un riepilogo di fine progetto 43 Transizione Questa fase si basa quasi completamente sulle attività relative all implementazione e al test Tuttavia, un minimo di progettazione può essere necessario per correggere eventuali errori di progettazione scoperti durante il beta test Ognuno di questi tre flussi di lavoro ha un obiettivo ben definito Progettazione Rivedere il modello se sono insorti problemi durante il beta test Implementazione Adattare il software al rilascio presso i siti utente e correggere i difetti scoperti durante il beta test Test Beta test e test di accettazione eseguiti presso i siti clienti 44 Page 22

23 Transizione Milestone di questa fase è la realizzazione del prodotto finito rilasciato agli utenti A questa milestone corrisponderà il rilascio di alcuni artefatti: Prodotto software Pianificazione del supporto tecnico Manuale utente 45 Flusso di Lavoro di Implementazione Il flusso di lavoro di implementazione ha l obiettivo di trasformare il modello di progettazione in codice eseguibile Si concentra sulla produzione di codice Dal punta di vista del progettista ha anche l obiettivo di produrre il modello di implementazione del sistema In alcuni casi, il modello di implementazione può essere un sottoprodotto dell attività di implementazione Il modello viene estratto automaticamente dal codice tramite tecniche di reverse engineering In altri casi, il modello di implementazione è necessario perché: Si vuole generare il codice dal modello tramite tecniche di forward engineering Si vuole assegnare le classi e le interfacce a dei componenti in modo da massimizzare il loro riuso 46 Page 23

24 Modello di Implementazione Il modello di implementazione è una vista del modello di progettazione Ogni sottosistema di implementazione realizza esattamente lo stesso insieme di classi e interfacce del sottosistema di progettazione I sottosistemi di progettazione sono entità logiche che raggruppano elementi di progettazione I sottosistemi di implementazione corrispondono a meccanismi di raggruppamento del linguaggio di programmazione scelto per l implementazione Gli artefatti utilizzati nel modello di implementazione sono: Il diagramma dei componenti, che ha lo scopo di modellare le dipendenze tra I componenti software che costituiscono il sistema Il diagramma di deployment: che ha lo scopo di modellare i nodi fisici su cui verrà dislocato il software e le relazioni tra questi nodi 47 Cosa è un Componente? Un componente è una parte, fisica e sostituibile, di un sistema che Contiene un certo numero di classi Rispetta un certo insieme di interfacce Ne fornisce una realizzazione Un componente può essere considerato un unità di riuso Un componente può essere composto da altri componenti 48 Page 24

25 Cosa è un Componente? I seguenti artefatti possono essere considerati componenti: File di codice sorgente Sottosistema di implementazione Controllo ActiveX JavaBean Enterprise JavaBean Servlet Java Java Server Page 49 Page 25

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

2. Ciclo di Vita e Processi di Sviluppo

2. Ciclo di Vita e Processi di Sviluppo 2. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 2. Ciclo di Vita e Processi di

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

Ciclo di vita del progetto

Ciclo di vita del progetto IT Project Management Lezione 2 Ciclo di vita del progetto Federica Spiga A.A. 2009-2010 1 Ciclo di vita del progetto Il ciclo di vita del progetto definisce le fasi che collegano l inizio e la fine del

Dettagli

13. Ciclo di Vita e Processi di Sviluppo

13. Ciclo di Vita e Processi di Sviluppo 13. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 13. Ciclo di Vita e Processi

Dettagli

UniRoma2 - Ingegneria del Software 1 1

UniRoma2 - Ingegneria del Software 1 1 Object Oriented Analysis - OOA La fase di OOA definisce, secondo un approccio ad oggetti, COSA un prodotto software deve fare (mentre la fase di OOD definisce, sempre secondo un approccio ad oggetti, COME

Dettagli

Progettazione orientata agli oggetti Introduzione a UML

Progettazione orientata agli oggetti Introduzione a UML Progettazione orientata agli oggetti Introduzione a UML Claudia Raibulet raibulet@disco.unimib.it Il processo di sviluppo software Rappresenta un insieme di attività per la specifica, progettazione, implementazione,

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

Linguaggi di Programmazione I Lezione 5

Linguaggi di Programmazione I Lezione 5 Linguaggi di Programmazione I Lezione 5 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 1 aprile 2008 Diagrammi UML 3 UML: richiami..........................................................

Dettagli

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist www.roccatello.it

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist <eduard.roccatello@3dgis.it> www.roccatello.it Modellazione e progettazione con UML Eduard Roccatello 3D GIS Specialist www.roccatello.it Object Oriented Analysis and Design Consente di modellare un sistema attraverso l

Dettagli

Indice. Prefazione alla seconda edizione italiana XVII. Introduzione. Parte 1 Introduzione all UML e all UP 1

Indice. Prefazione alla seconda edizione italiana XVII. Introduzione. Parte 1 Introduzione all UML e all UP 1 00PrPag 19-07-2006 15:22 Pagina V Prefazione alla seconda edizione italiana Introduzione XV XVII Parte 1 Introduzione all UML e all UP 1 Capitolo 1 UML 3 1.1 Contenuto del capitolo 3 1.2 Cos è l UML? 3

Dettagli

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Ingegneria del Software A. A. 2008-2009. Class Discovery E.

Corso di Laurea Specialistica in Ingegneria Informatica. Corso di Ingegneria del Software A. A. 2008-2009. Class Discovery E. Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Class Discovery E. TINELLI Contenuti Classi di analisi: definizione ed esempi Tecniche per la definizione

Dettagli

La progettazione del software nelle piccole o micro imprese

La progettazione del software nelle piccole o micro imprese La progettazione del software nelle piccole o micro imprese Il contenuto di questo documento è strettamente confidenziale, la visione dello stesso è consentita solo al personale di FadeOut Snc e della

Dettagli

Introduzione ad UML. Perché modelliamo

Introduzione ad UML. Perché modelliamo Introduzione ad UML Pag. 1 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare la

Dettagli

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

Automazione della gestione degli ordini d acquisto di una società di autonoleggio

Automazione della gestione degli ordini d acquisto di una società di autonoleggio Automazione della gestione degli ordini d acquisto di una società di autonoleggio Professore Gaetanino Paolone Studenti Paolo Del Gizzi Maurizio Di Stefano 1 INDICE INTRODUZIONE.pag.3 IL PIANO METODOLOGICO

Dettagli

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1 Introduzione Il software e l ingegneria del software Marina Mongiello Ingegneria del software 1 Sommario Il software L ingegneria del software Fasi del ciclo di vita del software Pianificazione di sistema

Dettagli

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi metodologie a.a. 2003-2004 1 metodologia una serie di linee guida per raggiungere certi obiettivi più formalmente: un processo da seguire documenti o altri elaborati da produrre usando linguaggi più o

Dettagli

Sommario Unified Modeling Language Ing. Gianluca Di Tomassi www.ditomassi.it Modelli del processo SW Modello a cascata Sviluppo iterativo del SW Modello incrementale Modello a spirale Unified Modeling

Dettagli

Sistemi Informativi. Unified Modeling Language e Unified Process Introduzione. Introduzione allo Unified Modeling Language

Sistemi Informativi. Unified Modeling Language e Unified Process Introduzione. Introduzione allo Unified Modeling Language UNIVERSITÀ DI PISA CORSO DI SISTEMI INFORMATIVI A.A. 2005-06 Sistemi Informativi F. Marcelloni M.G. Cimino Unified Modeling Language e Unified Process Introduzione Sistemi Informativi 1 Introduzione allo

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

La specifica del problema

La specifica del problema 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a

Dettagli

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini ANALISI E PROGETTAZIONE OBJECT ORIENTED Lorenzo Saladini 1. Introduzione In questo capitolo vengono presentati alcuni degli elementi necessari al corretto sviluppo di sistemi informatici secondo una metodologia

Dettagli

Paradigma object-oriented

Paradigma object-oriented Paradigma object-oriented Dati & Comportamento Implementazione trasparente dei servizi Facile mantenimento Omogeneità nella gerarchia dati-funzioni Procedural approach OO approach Data hierarchy Replaced

Dettagli

Dalla progettazione concettuale alla modellazione di dominio

Dalla progettazione concettuale alla modellazione di dominio Luca Cabibbo A P S Analisi e Progettazione del Software Dalla progettazione concettuale alla modellazione di dominio Capitolo 91 marzo 2015 Se qualcuno vi avvicinasse in un vicolo buio dicendo psst, vuoi

Dettagli

Corso di Laurea Triennale in Ingegneria Informatica. Corso di Ingegneria del software A. A. 2004-2005. Marina Mongiello

Corso di Laurea Triennale in Ingegneria Informatica. Corso di Ingegneria del software A. A. 2004-2005. Marina Mongiello Corso di Laurea Triennale in Ingegneria Informatica Corso di Ingegneria del A. A. 2004-2005 1 La progettazione È applicata indipendentemente dal modello di processo utilizzato. Parte dal punto in cui sono

Dettagli

Principi di Progettazione del Software a.a. 2015-2016" Introduzione a UML. Requisiti e casi d uso! Prof. Luca Mainetti! Università del Salento!

Principi di Progettazione del Software a.a. 2015-2016 Introduzione a UML. Requisiti e casi d uso! Prof. Luca Mainetti! Università del Salento! Principi di Progettazione del Software a.a. 2015-2016" Introduzione a UML. Requisiti e casi d uso! Prof. Luca Mainetti! Università del Salento! Obiettivi della lezione" Introdurre il linguaggio UML per

Dettagli

4.1 Che cos è l ideazione

4.1 Che cos è l ideazione Luca Cabibbo Analisi e Progettazione del Software Ideazione (non è la fase dei requisiti) Capitolo 4 marzo 2013 Il meglio è nemico del bene. Voltaire 1 *** AVVERTENZA *** I lucidi messi a disposizione

Dettagli

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Fondamenti di Informatica Linguaggi di Programmazione Michele Tomaiuolo Linguaggi macchina I

Dettagli

Progettazione di Applicazioni Web

Progettazione di Applicazioni Web 1 Argomenti della lezione Progettazione di Applicazioni Web Sviluppo delle applicazioni Processo di sviluppo Formalismi grafici di supporto diagrammi UML (cenni) Scelta dell architettura Sviluppo di applicazioni

Dettagli

Laboratorio di Progettazione di Sistemi Software Introduzione

Laboratorio di Progettazione di Sistemi Software Introduzione Laboratorio di Progettazione di Sistemi Software Introduzione Valentina Presutti (A-L) Riccardo Solmi (M-Z) Indice degli argomenti Introduzione all Ingegneria del Software UML Design Patterns Refactoring

Dettagli

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia BANDO ACQUISIZIONI Prodotti Software ALLEGATO 6.3 Capitolato Tecnico Piattaforma per l Analisi e la Progettazione di alto livello del Software Allegato 6.3: capitolato tecnico Pag. 1 1 Ambiente di Analisi

Dettagli

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo

I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo Luca Cabibbo Analisi e Progettazione del Software Sviluppo iterativo, evolutivo e agile Capitolo 2 marzo 2015 Lo sviluppo iterativo dovrebbe essere utilizzato solo per i progetti che si desidera che vadano

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica INGEGNERIA DEL SOFTWARE Prof. Paolo Salvaneschi 1 Obiettivi Scopi del corso: - Fornire gli elementi di base della disciplina,

Dettagli

Lezione 5: Progettazione di Software e Database. Ingegneria del Software. Il Software 19/11/2011. Dr. Luca Abeti

Lezione 5: Progettazione di Software e Database. Ingegneria del Software. Il Software 19/11/2011. Dr. Luca Abeti Lezione 5: Progettazione di Software e Database Dr. Luca Abeti Ingegneria del Software L ingegneria del software è la disciplina che studia i metodi e gli strumenti per lo sviluppo del software e la misura

Dettagli

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML)

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) a cura di Giacomo PISCITELLI Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Questi appunti sono ricavati da una

Dettagli

ISTITUTO TECNICO ECONOMICO MOSSOTTI

ISTITUTO TECNICO ECONOMICO MOSSOTTI CLASSE III INDIRIZZO S.I.A. UdA n. 1 Titolo: conoscenze di base Conoscenza delle caratteristiche dell informatica e degli strumenti utilizzati Informatica e sistemi di elaborazione Conoscenza delle caratteristiche

Dettagli

Obiettivo della lezione. Casi d uso. Casi d uso (use cases) Scenari d interazione

Obiettivo della lezione. Casi d uso. Casi d uso (use cases) Scenari d interazione Obiettivo della lezione Casi d uso La modellazione dei requisiti funzionali I casi d uso Gli attori Gli scenari Come scrivere casi d uso Casi d uso (use cases) Scenari d interazione Proposti da Ivar Jacobson

Dettagli

Il modello Entity-Relationship per il progetto delle basi di dati

Il modello Entity-Relationship per il progetto delle basi di dati 1 Il modello Entity-Relationship per il progetto delle basi di dati Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Le metodologie di progettazione delle Basi di Dati 2 Una metodologia

Dettagli

Configuratore di Prodotto Diapason

Configuratore di Prodotto Diapason Configuratore di Prodotto Diapason Indice Scopo di questo documento...1 Perché il nuovo Configuratore di Prodotto...2 Il configuratore di prodotto...3 Architettura e impostazione tecnica...5 Piano dei

Dettagli

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)

Dettagli

Linguaggi di Programmazione I Lezione 6

Linguaggi di Programmazione I Lezione 6 Linguaggi di Programmazione I Lezione 6 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 8 aprile 2008 Analisi di oggetti e classi 3 Introduzione............................................................

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Cosa significa che il SW è non lineare? Piccoli cambiamenti nel codice portano a grandi cambiamenti di comportamento

Cosa significa che il SW è non lineare? Piccoli cambiamenti nel codice portano a grandi cambiamenti di comportamento Cosa significa che il SW è non lineare? Piccoli cambiamenti nel codice portano a grandi cambiamenti di comportamento Cosa s'intende per Information Hiding? Impedire l'accesso a dettagli implementativi

Dettagli

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it Progetto Struttura del documento di specifica dei requisiti, Casi d uso manuel.comparetti@iet.unipi.it 1 Documenti da produrre Il progetto deve comprendere i seguenti documenti: Documento di specifica

Dettagli

Object Oriented Software Design

Object Oriented Software Design Dipartimento di Informatica e Sistemistica Antonio Ruberti Sapienza Università di Roma Object Oriented Software Design Corso di Tecniche di Programmazione Laurea in Ingegneria Informatica (Canale di Ingegneria

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Analisi Giulio Destri Ing. del software: Analisi - 1 Scopo del modulo Definire

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207.

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207. Durante le attività di sviluppo del software applicativo è spesso utilizzato un ciclo di vita incrementale il cui schema di processo è sintetizzato nella figura seguente. In legenda sono riportate le fasi

Dettagli

Indice. Prefazione all edizione italiana

Indice. Prefazione all edizione italiana Indice Prefazione all edizione italiana XV Capitolo 1 Il software e l ingegneria del software 1 1.1 L evoluzione del ruolo del software 3 1.2 Il software 5 1.3 La natura mutevole del software 8 1.4 Il

Dettagli

7.1 Livello di completezza degli esempi

7.1 Livello di completezza degli esempi Luca Cabibbo Analisi e Progettazione del Software Capitolo 7 marzo 2013 Buono, poco costoso, rapidamente. Puoi scegliere due di queste caratteristiche. Anonimo 1 *** AVVERTENZA *** I lucidi messi a disposizione

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE Allegato 1.4 Cicli di vita del software Pagina 1 di 20 Indice 1 CICLI DI VITA... 3 1.1 Ciclo di Sviluppo...3 1.2 Ciclo di Manutenzione...5 2 LE FASI PROGETTUALI...

Dettagli

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE Allegato 1.4 Cicli di vita del software Pagina 1 di 20 Indice 1 CICLI DI VITA... 3 1.1 Ciclo di Sviluppo... 3 1.2 Ciclo di Manutenzione... 5 2 LE FASI PROGETTUALI...

Dettagli

UML - Unified Modeling Language

UML - Unified Modeling Language UML E CASI D USO UML - Unified Modeling Language Linguaggio stardardizzato per identificare e modellizzare le specifiche di un S.I. Coerente con il paradigma della programmazione ad oggetti Definito a

Dettagli

La ingegneria del software e i formalismi. Ingegneria del software. Lezione n. 5. Lezione n. 5.1

La ingegneria del software e i formalismi. Ingegneria del software. Lezione n. 5. Lezione n. 5.1 La ingegneria del software e i formalismi Lezione n. 5 Ingegneria del software Lezione n. 5. Creazione di un software: dal problema ai risultati (/2) Creazione di un software: dal problema ai risultati

Dettagli

Use Case Driven Object Modeling: ICONIX

Use Case Driven Object Modeling: ICONIX Use Case Driven Object Modeling: ICONIX Un esempio di specifica, analisi, progetto e sviluppo utilizzando ICONIX Ditta di Noleggio Dvd Un sistema per la gestione di una ditta di noleggio dvd che ha più

Dettagli

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE Allegato 1.4 Cicli di vita del software Pagina 1 di 16 Indice 1 CICLI DI VITA... 3 1.1 Ciclo di Sviluppo... 3 1.2 Ciclo di Manutenzione... 5 2 LE FASI PROGETTUALI...

Dettagli

CORSO DI PROGRAMMAZIONE JAVA

CORSO DI PROGRAMMAZIONE JAVA CORSO DI PROGRAMMAZIONE JAVA Corso di Programmazione Java Standard Edition ( MODULO A) OBIETTIVI ll corso ha come obiettivo quello di introdurre la programmazione a oggetti (OOP) e di fornire solide basi

Dettagli

Principi di programmazione OO

Principi di programmazione OO Principi di programmazione OO Ing. Paolo Vaccari Giovedì 9 e 16 Marzo 2006 Corsi Speciali L.143/04 - SSIS TOSCANA 2005/2006 Principi di programmazione OO Prima lezione: Programmazione

Dettagli

Una metodologia per la specifica di software basato su componenti

Una metodologia per la specifica di software basato su componenti Luca Cabibbo Architetture Software Una metodologia per la specifica di software basato su componenti Dispensa ASW 445 ottobre 2014 La mappa non è il territorio. Douglas R. King 1 -Fonti [UML Components],

Dettagli

Progettazione ad oggetti

Progettazione ad oggetti Progettazione ad oggetti Gli elementi reali vengono modellati tramite degli oggetti Le reazioni esistenti nel modello reale vengono trasformate in relazioni tra gli oggetti Cos'è un oggetto? Entità dotata

Dettagli

Ingegneria del Software 2

Ingegneria del Software 2 Politecnico di Milano Anno Accademico 2010/2011 Ingegneria del Software 2 Corso della Prof.ssa Elisabetta Di Nitto Stefano Invernizzi Facoltà di Ingegneria dell Informazione Corso di Laurea Magistrale

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

Dettagli

PROGETTAZIONE DEL SOFTWARE

PROGETTAZIONE DEL SOFTWARE PROGETTAZIONE DEL SOFTWARE EMILIANO CASALICCHIO DIPARTIMENTO DI INFORMATICA E SISTEMISTICA SAPIENZA UNIVERSITÀ DI ROMA SEDE DI RIETI HTTP://WWW.CE.UNIROMA2.IT/COURSES/PSW! Cos è UML UNIFIED MODELING LANGUAGE!

Dettagli

Introduzione a UML. Adriano Comai. http://www.analisi-disegno.com. versione 19 marzo 2010. Adriano Comai. Introduzione a UML Pag.

Introduzione a UML. Adriano Comai. http://www.analisi-disegno.com. versione 19 marzo 2010. Adriano Comai. Introduzione a UML Pag. Introduzione a UML versione 19 marzo 2010 http://www.analisi-disegno.com Introduzione a UML Pag. 1 Obiettivo di questa introduzione fornire alcuni elementi di base su UML introdurre i diagrammi fornire

Dettagli

Studio di fattibilità (2) Identificazione ed analisi dei requisiti

Studio di fattibilità (2) Identificazione ed analisi dei requisiti Prime fasi nella produzione del software &RUVR GL,QJHJQHULD GHO 6RIWZDUH Capitolato d appalto o doc. formale di richiesta prodotto Incontri con il committente e/o interviste Esercitazione Studio del dominio

Dettagli

Caso di Studio: Avant Dernier

Caso di Studio: Avant Dernier Caso di Studio: Avant Dernier Specifiche: Nel gioco si affrontano 4 giocatori, ciascuno individuato con un numero progressivo (da 1 a 4). Inizialmente, i giocatori ricevono 5 carte ciascuno, e una carta

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2.

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2. Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

Processi di Sviluppo Software Introduzione. Giuseppe Calavaro

Processi di Sviluppo Software Introduzione. Giuseppe Calavaro Processi di Sviluppo Software Introduzione Giuseppe Calavaro Processi di sviluppo software - Agenda Differenza tra Programmazione e Progettazione SW I Processi di Sviluppo Software Waterfall Spirale RUP

Dettagli

LEZIONE 9 - Linguaggi di Modellazione & UML

LEZIONE 9 - Linguaggi di Modellazione & UML Laboratorio di Ingegneria del Software a.a. 2013-2014 LEZIONE 9 - Linguaggi di Modellazione & UML Catia Trubiani Gran Sasso Science Institute (GSSI), L Aquila catia.trubiani@gssi.infn.it Cosa sono? 2 1

Dettagli

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

Ingegneria del Software. Introduzione ai pattern

Ingegneria del Software. Introduzione ai pattern Ingegneria del Software Introduzione ai pattern 1 Definizione di pattern [dal [dal vocabolario vocabolario Garzanti] Garzanti] Alcuni esempi: Pattern architetturale Pattern di circuito stampato Pattern

Dettagli

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti Alessio Bechini - Corso di - Il paradigma OO e le relative metodologie di progettazione Metodologie OO Programmazione orientata agli oggetti La programmazione ad oggetti (OOP) è un paradigma di programmazione

Dettagli

REFERENZIAZIONI 2001) NUP

REFERENZIAZIONI 2001) NUP Agenzia del Lavoro Provincia Autonoma di Trento PROFILO FORMATIVO Profilo professionale e percorso formativo DENOMINAZIONE FIGURA PROFESSIONALE - TECNICO INFORMATICO PROGRAMMATORE SOFTWARE E APPLICAZIONI

Dettagli

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

Analisi Modelli per la specifica dei requisiti

Analisi Modelli per la specifica dei requisiti Modelli per la specifica dei requisiti Modelli semantici dei dati Entità-Relazioni (E-R) Modelli orientati all elaborazione dati Diagrammi di Flusso dei Dati (Data-Flow Diagrams, DFD) Modelli orientati

Dettagli

!"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&) !"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9

!#$%&&'()#*%+%+!#$',,'()#*%+ -)%*&'&'+'$.)+-$$%&&) !#$%&&'(%)'*+%,#-%#.'%&'#/0)-+#12+3,)4+56#7+#.')8'9 !"#$%&&'()#*%+%+!"#$"',,'()#*%+ -")%*&'&'+'$.)+-$$%&&)!"#$%&&'(%)'*+%",#-%"#.'%&'#/0)-+#12"+3,)4+56#7+#.')8'9 Slide 1 Paradigmi di Programmazione! Un linguaggio supporta uno stile di programmazione se

Dettagli

UML. Una introduzione incompleta. UML: Unified Modeling Language

UML. Una introduzione incompleta. UML: Unified Modeling Language UML Una introduzione incompleta 1/23 UML: Unified Modeling Language Lo Unified Modeling Language (UML) è una collezione di notazioni grafiche che aiuta a progettare sistemi software, specialmente quelli

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software.

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Test Giulio Destri Ing. del Software: Test - 1 Scopo del modulo Definire

Dettagli

Ingegneria del Software T. 2. Analisi orientata agli oggetti

Ingegneria del Software T. 2. Analisi orientata agli oggetti Ingegneria del Software T 2. Analisi orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare

Dettagli

Design Patterns. Sommario. Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 1. Design Patterns DIB 2

Design Patterns. Sommario. Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 1. Design Patterns DIB 2 DIB 1 Sommario Architettura a 3 Livelli Concetti Generali Presentazione Dominio Sorgente Dati DIB 2 Architettura a 3 Livelli DIB 3 Architettura a 3 Livelli Presentazione Gestione dell interazione degli

Dettagli

Appunti lezione Database del 07/10/2015

Appunti lezione Database del 07/10/2015 Appunti lezione Database del 07/10/2015 Nelle lezioni precedenti si è visto come qualunque applicazione informativa è almeno formata da tre livelli o layers che ogni progettista conosce e sa gestire: Livello

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Ingegneria del Software. Processi di Sviluppo

Ingegneria del Software. Processi di Sviluppo Ingegneria del Software Processi di Sviluppo Ingegneria del Software: Tecnologia Stratificata tools metodi processi Focus sulla qualità Ingegneria del Software: Tecnologia Stratificata (2) Qualità Elemento

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Ingegneria del Software - Il Ciclo Lungo

Ingegneria del Software - Il Ciclo Lungo Ingegneria del Software - Il Ciclo Lungo Alessandro Martinelli alessandro.martinelli@unipv.it 10 Marzo 2014 Il Ciclo Lungo Il Versioning e la Condivisione di Codice Organizzazione dei Pacchetti La Modellazione

Dettagli

Meet O Matic. Design Document. Autori: Matteo Maggioni Luca Mantovani. Matricola: 721923 721014

Meet O Matic. Design Document. Autori: Matteo Maggioni Luca Mantovani. Matricola: 721923 721014 Meet O Matic Design Document Autori: Matteo Maggioni Luca Mantovani Matricola: 721923 721014 1 Indice 1 Introduzione 4 2 Architettura 4 3 Definizione della base di dati 6 3.1 Tabelle, campi e chiavi primarie.................

Dettagli

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO DIREZIONE EMITTENTE CONTROLLO DELLE COPIE Il presente documento, se non preceduto dalla pagina di controllo identificata con il numero della copia, il destinatario, la data e la firma autografa del Responsabile

Dettagli

Fasi del ciclo di vita del software (riassunto) Progetto: generalità. Progetto e realizzazione (riassunto)

Fasi del ciclo di vita del software (riassunto) Progetto: generalità. Progetto e realizzazione (riassunto) Università degli Studi di Roma La Sapienza Facoltà di Ingegneria Sede di Latina Laurea in Ingegneria dell Informazione Fasi del ciclo di vita del software (riassunto) Corso di PROGETTAZIONE DEL SOFTWARE

Dettagli