Obiettivi. Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti UML Use Case Esercizi

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Obiettivi. Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti UML Use Case Esercizi"

Transcript

1 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti UML Use Case Esercizi Obiettivi Nelle lezioni precedenti abbiamo modellato il dominio business e i dati L obiettivo di oggi é: Comprendere cosa sia una specifica dei requisiti. Acquisire gli strumenti (i.e. imparare un linguaggio) per disegnare i requisiti funzionali. 2

2 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti UML Use Case Esercizi Modello di riferimento 4

3 Flusso di lavoro di modellazione Raccolta Requisiti IT 5 Cosa vuol dire modellare i requisiti? L analisi dei processi aziendali porta ad una loro maggiore comprensione. Dalla definizione fino al livello di attività è possibile arrivare, attraverso una procedura di selezione detta mappatura dei requisiti, a determinare quali attività devono essere supportate da un sistema informativo e in che modo. La mappatura dei requisiti consente dunque di determinare, successivamente alla analisi di processo, quali sono le caratteristiche, dal punto di vista dell utente, che un sistema informativo deve avere per supportare adeguatamente un dato processo. Questo porta alla specifica dei requisiti del sistema informativo. 6

4 Requisiti funzionali Il requisiti funzionali definiscono che cosa un sistema informativo deve fare (i.e. le funzionalità), a prescindere dalla sua implementazione informatica, cioè dal come Lo scopo è descrivere le operazioni (i.e. le funzionalità) che un utente può effettuare con il sistema 7 Requisiti funzionali vs requisiti non funzionali I requisiti non funzionali descrivono altre caratteristiche che il sistema deve possedere a prescindere dalle funzionalità, per esempio: o Qualità (e.g. tempo di risposta del sistema, tempo di aggiornamento dei valori); o Facilità d uso (e.g. tempo di addestramento per gli utilizzatori, numero di maschere di aiuto); o Affidabilità (e.g. Tempo medio di malfunzionamento del sistema, disponibilità del sistema); o Robustezza (e.g. Percentuale di eventi causante malfunzionamenti, Tempo per il riavvio dopo un malfunzionamento); o Altri (e.g. sicurezza) I requisiti non funzionali sono fuori ambito 8

5 Raccolta e descrizione dei requisiti I requisiti possono essere descritti da asserzioni in linguaggio naturale, e.g. ATM Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 9 Raccolta e descrizione dei requisiti - funzionali I requisiti possono essere descritti da asserzioni in linguaggio naturale, e.g. ATM Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 10

6 Raccolta e descrizione dei requisiti non funzionali I requisiti possono essere descritti da asserzioni in linguaggio naturale, e.g. ATM Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 11 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti UML Use Case Esercizi

7 Perchè UML? L utilizzo del linguaggio naturale nella descrizione delle specifiche dei requisiti porta spesso ad incomprensioni e ad una scarsa organizzazione dei requisiti stessi, mentre l uso di notazioni diverse in fase di progettazione non consentiva un efficace comunicazione tra tutti coloro che dovevano leggere il progetto e renderlo realtà traducendolo in effettivo codice sorgente. L UML (Unified Modeling Language) nasce come unione di diverse modalità di diagrammazione e descrizione volte a rendere più chiare ed efficaci le fasi di stesura delle specifiche dei requisiti e della progettazione dei sistemi The Three Amigos (Jacobson, Raumbaugh, Booch) sono considerati i fondatori dell UML 13 Il problema del linguaggio 14

8 UML views La versione base dell UML si occupa di fornire un linguaggio comune per la specifica dei requisiti IT e per la progettazione, il collaudo e la manutenzione del software che implementa questi requisiti. Per la specifica delle funzionalità di un sistema si utilizza il diagramma dei casi d uso User View 15 Use case - definizione Un caso d uso rappresenta un insieme di azioni compiute da un sistema che porta ad un risultato osservabile di valore per uno o più attori esterni al sistema o Il sistema deve prevedere la funzione di prelievo. They are used to capture the requirements of a system, that is, what a system is supposed to do UML Superstructure Specification, v2.3, OMG Proposti da Ivar Jacobson nel 1992 all interno di Objectory. 16

9 Use case diagram - Attori Actors Rappresenta un utente esterno al sistema che ne utilizza le funzionalità ( NON è obbligatorio che sia un umano) Ruolo che una persona o un dispositivo hardware o un altro sistema gioca rispetto al sistema Gli attori eseguono casi d uso Prima si cercano gli attori, poi i loro casi d uso Gli attori ottengono valore dal caso d uso o vi partecipano L attore scambia informazioni col sistema Un attore può essere contenitore di informazioni Un attore può anche rappresentare un altro sistema 17 Use case diagram Use Cases Use cases Rappresenta una funzionalità, ovvero un comportamento richiesto al sistema Rappresenta uno scenario di interazione (un dialogo) tra gli utilizzatori e il sistema: il cliente richiede l elenco dei prodotti il sistema propone i prodotti disponibili il cliente sceglie i prodotti che desidera il sistema fornisce il costo totale dei prodotti selezionati il cliente conferma l ordine il sistema comunica l accettazione dell ordine L attenzione si focalizza sull interazione, non sulle attività interne al sistema Subject Rappresenta il sistema in esame al quale si applicano i casi d uso Subject Use Case 18

10 Flusso degli eventi Ogni caso d uso Ha una sequenza di transizioni normale o di base Può avere varie sequenze alternative Ha varie sequenze di transazioni eccezionali per la gestione di situazioni erronee 19 Use Case - Descrizione Un caso d uso descrive l interazione tra un attore e un sistema. Per ogni caso d uso è necessario allegare una descrizione semistrutturata tra l attore e il sistema o L utente fa. o Il sistema fa 20

11 Use Case Esempio 0 CU 3: INSERIMENTO CONFERMA D ORDINE [CU3.1] Il commerciale riceve da un cliente una conferma d ordine o un ordine [CU3.2] Il commerciale apre la finestra di Conferma ordinativo per un dato cliente [CU3.3] Il commerciale carica le previsioni effettuate da se stesso per un determinato articolo e periodo temporale [CU3.4] Il sistema evidenza se l articolo viene prodotto in make oppure in buy [CU3.5] Il sistema evidenza il prezzo standard dell articolo e il tempo medio di realizzazione [CU3.5.1] Se presenti, il commerciale carica le previsioni effettuate ed inviate dal cliente, per un determinato articolo e periodo temporale [CU3.6] Il commerciale inserisce i dati di conferma ordinativo pervenuti dal cliente per un determinato articolo [CU3.6.1] Se i dati sono corrispondenti a una previsione, è sufficiente inserire i dati di conferma e trasformare la previsione in un impegno [CU 3.6.2] Se i dati non sono corrispondenti a una previsione, si inseriscono tutti i dati necessari e si crea un impegno 21 Esempio 1 Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 22

12 Use case diagram esempio 1 Il subject (sistema) è rappresentato da un rettangolo che visibilmente contiene i propri casi d uso Il caso d uso si rappresenta con una ellisse, con il nome del caso d uso segnato all interno oppure sotto la forma L actor si rappresenta con lo stickman, è sempre esterno al sistema ed è associato ai casi d uso che può attivare 23 Use Case Diagram - Associazioni Generalizzazione o Una associazione di generalizzazione (verso l alto) o specializzazione (verso il basso) rappresenta la relazione di IS-A tra gli elementi (i.e. padre e figlio) Inclusione o Una relazione di inclusione definisce che un caso d uso contiene il comportamento di un altro caso d uso Estensione o Una relazione di estensione specifica come e quando il comportamento di uno use case modifica il comportamento di un altro use case 24

13 Use case diagram - generalizzazione Una associazione di generalizzazione (verso l alto) o specializzazione (verso il basso) rappresenta la relazione di IS-A tra gli elementi Il figlio eredita il comportamento del padre e può aggiungere o modificarne il comportamento Il figlio può essere sostituito in qualsiasi punto appaia il genitore Una associazione di generalizzazione può riguardare sia due actors sia due use cases Si rappresenta con la freccia vuota Padre Figlio 25 Esempio 2 L amministratore di sistema, oltre ad avere accesso alle funzioni base dell ATM, deve essere in grado di registrare l ATM presso una specifica banca. Inoltre, deve aver accesso ai log del sistema per operare in caso di guasti 26

14 Use case diagram esempio 2 L Administrator eredita tutte le associazioni di Customer 27 Use case diagram - inclusione Definizione Una relazione di inclusione definisce che una caso d uso contiene il comportamento di un altro caso d uso Si usa per non descrivere più volte lo stesso flusso di eventi, inserendo il comportamento comune in un caso d uso a parte Evita di copiare parti di descrizione di casi d uso Notazione Si rappresenta con una freccia tratteggiata e lo stereotype <<include>> Use case indipendente Card Identification 28

15 Esempio 3 Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo e trasferimento fondi devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 29 Use case diagram esempio 3 30

16 Use case diagram - estensione Definizione Una relazione di estensione specifica come e quando il comportamento di uno use case modifica il comportamento di un altro use case Utile per specificare delle varianti dello use case Utilizzo Cattura il caso d uso di base Per ogni passo del flusso base chiedersi Cosa potrebbe andar male? Come potrebbe funzionare in modo diverso? Scrivere ogni variante come estensione del caso d uso 31 Use case diagram - estensione Notazione Si rappresenta con una freccia tratteggiata e lo stereotype <<extend>> Use case indipendente Perform ATM Transaction Specificare Extension Point Use Case Variante 32

17 Esempio 4 [ ] L utente deve poter ottenere una ricevuta se lo richiede. La ricevuta riporta il tipo di transazione, la data, il numero di conto, la somma ed il nuovo saldo 33 Use case diagram esempio 4 w/ Receipt 34

18 Confronto <<extend>> e <<include>> Scopo diverso <<include>> Fattorizza comportamento comune Spesso nessun attore è associato al caso d uso comune Sono possibili attori diversi per i casi d uso chiamanti <<extend>> Distingue le varianti Gli attori associati eseguono il caso d uso e tutte le estensioni L attore è collegato al caso base 35 Use Case Diagram - Osservazioni 1. Il diagramma dei casi d uso non dà informazione sulla sequenzialità degli use cases o Withdraw non avviene prima di Transfer Funds 2. Il diagramma serve a consolidare e razionalizzare i requisiti del sistema 3. Il diagramma serve a descrivere i requisiti ad alto livello di un sistema quindi deve essere comprensibile da tutti gli stakeholders 36

19 Use case - Osservazioni 1. Un caso d uso modella una funzionalità completa (flusso principale di esecuzione, flussi alternativi eventuali, condizioni di eccezione). Ricordarsi che l attore sta cercando di raggiungere il suo obiettivo 2. Un caso d uso è una funzionalità visibile esternamente dall utente e come tale da esso percepita, interagendo con il sistema/software 3. E eseguibile indipendentemente (i casi d uso possono condividere oggetti durante l esecuzione, ma ciascuna esecuzione è indipendente dalle altre) 4. Un caso d uso rappresenta una funzionalità che è iniziata da un attore (una volta iniziato, il caso d uso può poi interagire con altri attori) oppure da un evento che notifica un attore; è possibile che un attore riceva semplicemente i risultati di un caso d uso iniziato da un altro attore 5. Un caso d uso è produce sempre al termine dell esecuzione un risultato significativo e percepibile come tale esternamente da un altro attore 37 Esercizio Descrivere gli use cases evidenziati seguendo lo schema. Use Case: Main flow: Exceptional/alternative flow: w/ Receipt 38

20 Use case: Withdraw Main flow: Soluzione 1 Include (Card Identification) The system prompts user for amount to withdraw The user inputs the amount to withdraw The system checks the available funds of user The system checks the available money of ATM The system gives the money The system removes the amount from the account (print receipt) The system prints the current balance Exceptional flow If not sufficient funds or money available, prompt user for lower amount 39 Use case: Deposit Money Main flow: Soluzione 2 The system prompts user for amount of deposit The user inputs the amount of deposit and the bank account number The system opens the slot The system gets the cash (print receipt) The system prints the balance + the deposited amount Exceptional flow If the deposited cash is different from the declared amount, return the cash to the user 40

21 Use case: Card Identification Main flow: Soluzione 3 The user inserts the card The system prompts user for PIN number The user inputs the PIN number The system checks the validity of the card and the PIN number Exceptional flow If card or PIN is not valid, reject user 41 Esercizio TreniVeloci Il canale di vendita si appoggia ad un sistema per creare biglietti per i treni. Ogni soluzione puo avere un numero arbitrario di viaggiatori. Deve essere possibile visualizzare soluzioni alternative nel caso i posti siano terminati. 42

22 Use case: Crea Nuovo Biglietto Soluzione Precondition: Lo scenario di business è attivato quando si esprime l interesse ad acquistare una soluzione di viaggio, precedentemente selezionata. Main flow: 1. L attore specifica il numero di viaggiatori e la classe. 2. Il sistema visualizza i prezzi/tariffe disponibili (per i quali sono presenti un numero di posti pari al numero di viaggiatori selezionati), su quel treno/treni. 2 (a) Il sistema, qualora ci fosse disponibilità di posti a prezzi promozionali in soluzioni di viaggio contigue temporalmente a quella selezionata, le visualizza in modo propositivo (si veda il caso in cui il sistema riconosca il cliente fidelizzato). 3. Se lo scenario può richiedere la prenotazione di uno o più posti o servizi. (Prenotare posto o servizio). 4 Il sistema crea una nuova istanza di biglietto digitale in cui sono inseriti gli estremi del viaggio. Al biglietto creato è associato un codice identificativo univoco. 4 (a) Se richiesto dall utente, il biglietto può essere nominativo Exceptional flow 2 (b) Nel caso di indisponibilità di posti per la soluzione selezionata il sistema propone soluzioni contigue. 43 Errori tipici - Grafici <<extend>>: La freccia va dal caso variante al caso standard SI NO <<include>>: la freccia va dal caso più esterno al caso comune SI NO 44

23 Errori tipici - Scenario Mancata connessione alla rappresentazione grafica Se i casi d uso sono connessi allora la descrizione testuale deve denotare questo fatto: <<include>> include (Indentificazione Carta) <<extend>> extend(stampa ricevuta) Errore grave Diagrammi di flusso invece di casi d uso: un caso d uso è una sequenza di azioni, non una singola azione 46

24 Use Case specifica di Jacobson Attori Flusso eventi Precondizioni Eccezioni Criticità Caso d uso Descrizione Flussi alternativi Postcondizioni Frequenza Attori: attori afferenti o efferenti al caso Descrizione: frase che sintetizza la natura del caso Flusso Eventi: elenco numerato dei sottorequisiti che compongono il caso. Flussi Alternativi: modalità alternative di esecuzione del caso. Pre Condizioni: asserzioni che devono essere verificate perché il caso possa essere iniziato (si usa per stilare i piani di collaudo) Post Condizioni: asserzioni che devono essere verificate alla fine dell esecuzione del caso d uso (per i piani di collaudo) Eccezioni: possibili errori che devono essere rilevati nel sistema, di eventi che possono causare una esecuzione del caso d uso non lineare/corretta (per i piani di collaudo) Frequenza stimata di utilizzo (per decidere le priorità nel piano di sviluppo) Criticità (per stimare il rischio legato al requisito) 47 Caso d uso: specifica - esempio [CU3]: Inserimento Conferma d Ordine Attori Commerciale Breve Descrizione Permette di visualizzare le previsioni di ordine per cliente e articolo, inserire un ordine e confrontare la previsione con l ordine effettivo Flusso di Eventi Flusso Base [CU3.1] Il commerciale riceve da un cliente una conferma d ordine o un ordine. [CU3.2] Il commerciale apre la finestra di Conferma ordinativo per un dato cliente. [CU3.3] Il commerciale carica le previsioni effettuate da se stesso per un determinato articolo e periodo temporale [CU3.4] Il sistema evidenzia se l articolo è make or buy [CU3.5] Il sistema evidenzia il prezzo standard dell articolo e il tempo medio di realizzazione. [CU3.6] Se presenti, il commerciale carica le previsioni inviate dal cliente [CU3.7] Il commerciale inserisce i dati di conferma ordine pervenuti dal cliente. [CU3.8]Se i dati della conferma ordine sono corrispondenti alla previsione, è sufficiente inserire i dati di conferma e trasformare la previsione in un impegno. [CU3.9] Se i dati non sono corrispondenti a una previsione, si inseriscono i dati e si crea un impegno Flussi Alternativi [CU3.10] Il commerciale decide di non inserire l impegno perché l ordine è sensibilmente difforme alla previsione venditore. [CU3.11] Il commerciale decide di non inserire l impegno perché l ordine è sensibilmente difforme alla previsione cliente. [CU3.12] Il commerciale decide di non inserire l ordine perché il prezzo concordato è sensibilmente difforme al prezzo standard Pre Condizioni Al commerciale perviene un ordine da trasformare in impegno Post Condizioni E stato inserito un impegno a fronte dell ordinativo, oppure non si è in alcun modo modificata la situazione precedente Eccezioni Dati inseriti non validi Frequenza Stimata di Utilizzo (bassa, media, alta) ALTA Criticità (bassa, media, alta) ALTA 48

25 Esempi di documenti di specifica dei requisiti Standard IEEE/ANSI Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti UML Use Case Esercizi

26 Esercizi EX1 BivioMare

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 diagramma dei casi d uso

Il diagramma dei casi d uso Il diagramma dei casi d uso Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini Dott. Sara Zuppiroli A.A. 2010/2011 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011

Dettagli

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13 Raccolta dei Requisiti con i Casi D'uso Corso di Ingegneria del Software Anno Accademico 2012/13 I casi d uso I casi d'uso (use case) sono una tecnica utilizzata per identificare i requisiti funzionali

Dettagli

Ingegneria del Software I. UML - Use Case Diagram

Ingegneria del Software I. UML - Use Case Diagram Requisiti e casi d uso Unified Modeling Language Use Case Diagram 1 Il primo passo di qualsiasi processo di sviluppo è la definizione dei requisiti Definizione del Business Model Solitamente informale

Dettagli

Casi d uso (use cases)

Casi d uso (use cases) Casi d uso (use cases) proposti da Ivar Jacobson nel 1992 termine nuovo, ma tecnica consolidata (studio degli scenari di operatività degli utilizzatori di un sistema) sono i modi in cui il sistema può

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

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

Progettazione del Software A.A.2008/09

Progettazione del Software A.A.2008/09 Laurea in Ing. Informatica ed Ing. dell Informazione Sede di latina Progettazione del Software A.A.2008/09 Domenico Lembo* Dipartimento di Informatica e Sistemistica A. Ruberti SAPIENZA Università di Roma

Dettagli

Informatica Industriale Modello funzionale Casi d uso

Informatica Industriale Modello funzionale Casi d uso DIIGA - Università Politecnica delle Marche A.A. 2006/2007 Informatica Industriale Modello funzionale Casi d uso Luca Spalazzi spalazzi@diiga.univpm.it www.diiga.univpm.it/~spalazzi/ Informatica Industriale

Dettagli

Sistemi Informativi I Caso di studio con applicazione di UML

Sistemi Informativi I Caso di studio con applicazione di UML 9 CASO DI STUDIO CON APPLICAZIONE DI UML...2 9.1 IL CASO DI STUDIO...2 9.1.1 Il sistema attuale...2 9.2 IL PROBLEM STATEMENT...3 9.2.1 Formulazione del Problem statement per il caso proposto...3 9.3 USE

Dettagli

I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere.

I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere. UML e i Casi d USO I casi d uso specificano una sequenza di azioni che producono un risultato visibile agli attori del sistema. Essi nascono per fornire descrizioni delle capacità del sistema. I casi d

Dettagli

Elementi di UML (2) Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005

Elementi di UML (2) Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Elementi di UML (2) Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio di Sistemi e Processi Organizzativi UML

Dettagli

Basi di Dati. Programmazione e gestione di sistemi telematici

Basi di Dati. Programmazione e gestione di sistemi telematici Basi di Dati. Programmazione e gestione di sistemi telematici Coordinatore: Prof. Paolo Nesi Docenti: Prof. Paolo Nesi Dr.sa Michela Paolucci Dr. Emanuele Bellini UML La prima versione ufficiale risale

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

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

RIFERIMENTI ATTORI GLOSSARIO. ERRORI COMUNI REV. REQUISITI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova

RIFERIMENTI ATTORI GLOSSARIO. ERRORI COMUNI REV. REQUISITI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova RIFERIMENTI ERRORI COMUNI REV. REQUISITI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2014 2015 I riferimenti devono essere precisi

Dettagli

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Luciano Baresi Luciano Baresi 1 OMT Booch UML Sono simili in molti aspetti: Prescrivono un approccio passo-passo Consentono il passaggio dall analisi al progetto in modo omogeneo

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

Dettagli

Modellazione dei dati in UML

Modellazione dei dati in UML Corso di Basi di Dati e Sistemi Informativi Modellazione dei dati in UML Angelo Montanari Dipartimento di Matematica e Informatica Università degli Studi di Udine Introduzione UML (Unified Modeling Language):

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 del Software. Emiliano Casalicchio. Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti

Progettazione del Software. Emiliano Casalicchio. Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti Progettazione del Software L3.1 Emiliano Casalicchio Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti http://www.ce.uniroma2.it/courses/psw (Basato su materiale didattico

Dettagli

Esempio 1: CarMatch. Direzione centrale Sedi centrali per ogni paese Concessionarie locali di franchising UML 2

Esempio 1: CarMatch. Direzione centrale Sedi centrali per ogni paese Concessionarie locali di franchising UML 2 Esempio 1: CarMatch CarMatch è una società di franchising fondata con lo scopo di promuovere il car sharing CarMatch fornisce un servizio per i potenziali condivisori di automobili cercando di abbinare

Dettagli

Ingegneria del Software 11. Esercizi riassuntivi. Dipartimento di Informatica Università di Pisa A.A. 2014/15

Ingegneria del Software 11. Esercizi riassuntivi. Dipartimento di Informatica Università di Pisa A.A. 2014/15 Ingegneria del Software 11. Esercizi riassuntivi Dipartimento di Informatica Università di Pisa A.A. 2014/15 Descrizione del problema. L esempio descrive un sistema per il commercio, chiamato TradingSystem,

Dettagli

Ingegneria del Software 5. Esercizi sui casi d uso. Dipartimento di Informatica Università di Pisa A.A. 2014/15

Ingegneria del Software 5. Esercizi sui casi d uso. Dipartimento di Informatica Università di Pisa A.A. 2014/15 Ingegneria del Software 5. Esercizi sui casi d uso Dipartimento di Informatica Università di Pisa A.A. 2014/15 formulazione Per motivi di sicurezza, un organizzazione ha deciso di realizzare un sistema

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

3.6 Esempio 1: ATM_SYSTEM (Automated Teller Machine System)

3.6 Esempio 1: ATM_SYSTEM (Automated Teller Machine System) 3.6 Esempio 1: ATM_SYSTEM (Automated Teller Machine System) Il primo caso di studio da noi analizzato e denominato ATM_System (ATM: Automated Teller Machine) è relativo alla gestione di uno sportello bancomat.

Dettagli

Il diagramma dei casi d uso

Il diagramma dei casi d uso Il diagramma dei casi d uso Laboratorio di Sistemi e Processi Organizzativi Gian Piero Favini A.A. 2006-2007 Lab Sistemi e Processi Organizzativi () Il diagramma dei casi d uso A.A. 2006-2007 1 / 34 Tassonomia

Dettagli

5. Requisiti del Software II

5. Requisiti del Software II 5. Requisiti del Software II Come scoprire cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 5. Requisiti del Software II 1 / 42 Sommario 1 Generalità

Dettagli

13 - Gestione della Memoria nella Programmazione Orientata agli Oggetti

13 - Gestione della Memoria nella Programmazione Orientata agli Oggetti 13 - Gestione della Memoria nella Programmazione Orientata agli Oggetti Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/

Dettagli

Università degli Studi di Napoli Federico II. FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica LM. Progetto di un applicazione Android

Università degli Studi di Napoli Federico II. FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica LM. Progetto di un applicazione Android Università degli Studi di Napoli Federico II FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica LM Progetto di un applicazione Android Briscola bluetooth Candidati: Giuliano Formato Daniele

Dettagli

object oriented analysis

object oriented analysis object oriented analysis 1 attività di analisi l obiettivo dell analisi è raggiungere la piena comprensione del dominio di interesse lo strumento è la descrizione di un modello di dominio mediante un opportuno

Dettagli

UML e i casi d uso. Dr. Andrea Baruzzo. S i n t a s s i e L i n e e G u i d a. andrea.baruzzo@dimi.uniud.it

UML e i casi d uso. Dr. Andrea Baruzzo. S i n t a s s i e L i n e e G u i d a. andrea.baruzzo@dimi.uniud.it UML e i casi d uso S i n t a s s i e L i n e e G u i d a Dr. Andrea Baruzzo andrea.baruzzo@dimi.uniud.it Page 2 Agenda 1 Introduzione a UML: storia, approccio e motivazioni Cos è un modello (software)?

Dettagli

Un modello è ragionevole quando contiene queste tre caratteristiche.

Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Si consideri un agenzia che opera come biglietteria ferroviaria, aerea e navale, accettando diversi modi di pagamento. Si identifichino le principali entità coinvolte illustrando le gerarchie

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

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

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

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche.

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Un negozio di musica vende anche libri e riviste musicali. Si intende automatizzare l intero processo, dall approvvigionamento alla vendita. Si analizzino i requisiti e se ne rappresentino

Dettagli

Requisiti e Specifica

Requisiti e Specifica Università di Bergamo Dipartimento di Ingegneria gestionale, dell'informazione e della produzione INGEGNERIA DEL SOFTWARE Paolo Salvaneschi A3_2 V3.2 Requisiti e Specifica Tecniche e linguaggi Il contenuto

Dettagli

ANALISI FUNZIONALE E DIAGRAMMI DI FLUSSO DEI DATI DFD 1

ANALISI FUNZIONALE E DIAGRAMMI DI FLUSSO DEI DATI DFD 1 ANALISI FUNZIONALE E DIAGRAMMI DI FLUSSO DEI DATI DFD 1 Nelle lezioni precedenti Abbiamo definito il modello Entità- Associazione che serve a descrivere la struttura dei dati Abbiamo usato il modello per

Dettagli

Corso di Laurea in Informatica, A.A. 2014 2015

Corso di Laurea in Informatica, A.A. 2014 2015 ESERCITAZIONE DIAGRAMMI UML INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2014 2015 rcardin@math.unipd.it DIAGRAMMI DEI CASI D

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

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

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

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP)

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) 12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica,

Dettagli

5. Requisiti del Software II

5. Requisiti del Software II 5. Requisiti del Software II Come scoprire cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 5. Requisiti del Software II 1 / 22 Sommario 1 Generalità

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

Introduzione. Modellazione visuale. Perché UML. cont.) Perché UML (cont( Contributi principali

Introduzione. Modellazione visuale. Perché UML. cont.) Perché UML (cont( Contributi principali Unified Modeling Language Introduzione Davide Frey Corso di Ingegneria del Software Tratto dal materiale di Luciano aresi Politecnico di Milano Modellazione visuale Perché UML richiesta ordine consegna

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

LABORATORIO. 2 Lezioni su Basi di Dati Contatti:

LABORATORIO. 2 Lezioni su Basi di Dati Contatti: PRINCIPI DI INFORMATICA CORSO DI LAUREA IN SCIENZE BIOLOGICHE Gennaro Cordasco e Rosario De Chiara {cordasco,dechiara}@dia.unisa.it Dipartimento di Informatica ed Applicazioni R.M. Capocelli Laboratorio

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

Use case diagrams and templates in the specification of functional requirements

Use case diagrams and templates in the specification of functional requirements Software Engineering - A.A. 13/14 Use case diagrams and templates in the specification of functional requirements Enrico Vicario Dipartimento di Ingegneria dell'informazione Laboratorio Scienza e Tecnologia

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

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

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Mystic Pizza Gestione Pizzeria Scheda di Progetto Version 1.0 Data 19/03/2007 Indice degli argomenti 1. Introduzione 3 a. Scenario

Dettagli

UML un linguaggio universale per la modellazione del software. Adriano Comai

UML un linguaggio universale per la modellazione del software. Adriano Comai UML un linguaggio universale per la modellazione del software Adriano Comai 2 Finalmente uno standard per l analisi e disegno OO? L'obiettivo è ambizioso. Lo Unified Modeling Language (UML) vuole essere,

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

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

DESIGN PATTERN ESERCITAZIONE UML E DP INGEGNERIA DEL SOFTWARE. A quali pattern si riferiscono i tre schemi?

DESIGN PATTERN ESERCITAZIONE UML E DP INGEGNERIA DEL SOFTWARE. A quali pattern si riferiscono i tre schemi? ESERCITAZIONE UML E DP INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2014 2015 rcardin@math.unipd.it DESIGN PATTERN A quali pattern

Dettagli

Gestione del workflow

Gestione del workflow Gestione del workflow Stefania Marrara Corso di Tecnologie dei Sistemi Informativi 2004/2005 Progettazione di un Sistema Informativo Analisi dei processi Per progettare un sistema informativo è necessario

Dettagli

Analisi dei Requisiti e Specifica

Analisi dei Requisiti e Specifica Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi A3_2 V2.1 Analisi dei Requisiti e Specifica Tecniche e linguaggi Il contenuto del documento è liberamente utilizzabile

Dettagli

Gli algoritmi: definizioni e proprietà

Gli algoritmi: definizioni e proprietà Dipartimento di Elettronica ed Informazione Politecnico di Milano Informatica e CAD (c.i.) - ICA Prof. Pierluigi Plebani A.A. 2008/2009 Gli algoritmi: definizioni e proprietà La presente dispensa e da

Dettagli

ARTICOLO TECNICO Smart-MED-Parks: il Software

ARTICOLO TECNICO Smart-MED-Parks: il Software ARTICOLO TECNICO Smart-MED-Parks: il Software Introduzione Da Febbraio 2013, data di lancio del progetto Smart-MED-Parks, sono state realizzate un insieme di azioni al fine di: - Aumentare il livello di

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

DFD DISPENSA DEL CORSO DI SISTEMI INFORMATIVI UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA

DFD DISPENSA DEL CORSO DI SISTEMI INFORMATIVI UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA DISPENSA DEL CORSO DI SISTEMI INFORMATIVI Prof. Carlo Combi DFD Appunti a cura di E. Peri M. Devincenzi Indice 1

Dettagli

Elementi di UML (7): Diagrammi dei componenti e di deployment

Elementi di UML (7): Diagrammi dei componenti e di deployment Elementi di UML (7): Diagrammi dei componenti e di deployment Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio

Dettagli

[Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione

[Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione Luca Cabibbo Architetture Software Dispensa T 1 ottobre 2008 1 -Fonti [Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione [Larman] Applicare UML e i pattern, Capitolo

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

Visual Paradigm for UML Standard Edition(Universit?????? di Torino)

Visual Paradigm for UML Standard Edition(Universit?????? di Torino) Use Case Diagram Treno Visual Paradigm for UML Standard Edition(Universit?????? di Torino) RitiroBiglietto Ricercare e Presentare Software di ricerca soluzioni 0.. Extension Points p Ritiro a Casa Ritiro

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

Facoltà di Farmacia - Corso di Informatica

Facoltà di Farmacia - Corso di Informatica Basi di dati Riferimenti: Curtin cap. 8 Versione: 13/03/2007 1 Basi di dati (Database, DB) Una delle applicazioni informatiche più utilizzate, ma meno conosciute dai non informatici Avete già interagito

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

UML (ancora) Contenuto: Casi d uso Diagrammi di sequenza Componenti. 08 UML - 2010/11 G. Bucci 1

UML (ancora) Contenuto: Casi d uso Diagrammi di sequenza Componenti. 08 UML - 2010/11 G. Bucci 1 UML (ancora) Contenuto: Casi d uso Diagrammi di sequenza Componenti PROVVISORIO 08 UML - 2010/11 G. Bucci 1 Casi d uso Oggi l anaiisi dei casi d uso è considerata uno dei passi più importanti dell intero

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

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

DESIGN PATTERN ESERCITAZIONE PREPARAZIONE ALL ESAME, PARTE II INGEGNERIA DEL SOFTWARE. La soluzione corretta è la c)

DESIGN PATTERN ESERCITAZIONE PREPARAZIONE ALL ESAME, PARTE II INGEGNERIA DEL SOFTWARE. La soluzione corretta è la c) DESIGN PATTERN Barrare con una X la lettera del diagramma delle classi che fra i seguenti rappresenta in modo corretto il design pattern architetturale Model View Controller (MVC) ESERCITAZIONE PREPARAZIONE

Dettagli

Progetti e diagrammi di Gantt con Access

Progetti e diagrammi di Gantt con Access Progetti e diagrammi di Gantt con Access In questo articolo esamineremo un applicazione Access per la pianificazione delle attività dei progetti. L applicazione può essere facilmente utilizzata per soddisfare

Dettagli

Basi di dati. (Sistemi Informativi) teoria e pratica con Microsoft Access. Basi di dati. Basi di dati. Basi di dati e DBMS DBMS DBMS

Basi di dati. (Sistemi Informativi) teoria e pratica con Microsoft Access. Basi di dati. Basi di dati. Basi di dati e DBMS DBMS DBMS Basi di Basi di (Sistemi Informativi) Sono una delle applicazioni informatiche che hanno avuto il maggiore utilizzo in uffici, aziende, servizi (e oggi anche sul web) Avete già interagito (magari inconsapevolmente)

Dettagli

FONDAMENTI di INFORMATICA L. Mezzalira

FONDAMENTI di INFORMATICA L. Mezzalira FONDAMENTI di INFORMATICA L. Mezzalira Possibili domande 1 --- Caratteristiche delle macchine tipiche dell informatica Componenti hardware del modello funzionale di sistema informatico Componenti software

Dettagli

Progettazione di un sistema informativo aziendale

Progettazione di un sistema informativo aziendale Università degli Studi di Torino Corso in Sistemi Informativi Aziendali Professor M. Segnan Progettazione di un sistema informativo aziendale per un negozio online di articoli sportivi Eseguito da Giovanni

Dettagli

3. Gestione di un sistema operativo a interfaccia grafica (elementi di base) 3.1 Software

3. Gestione di un sistema operativo a interfaccia grafica (elementi di base) 3.1 Software Pagina 29 di 47 3. Gestione di un sistema operativo a interfaccia grafica (elementi di base) 3.1 Software Come abbiamo già detto in precedenza, l informatica si divide in due grandi mondi : l hardware

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

Internet ed i servizi di posta elettronica

Internet ed i servizi di posta elettronica Corso di introduzione all informatica Sommario Internet ed i servizi di posta elettronica Gaetano D Aquila La posta elettronica ed Outlook Express Sito internet del corso Prenotazione esami 2 Un po di

Dettagli

IL SISTEMA OPERATIVO IL SISTEMA OPERATIVO INTERFACCE TESTUALI INTERFACCE TESTUALI FUNZIONI DEL SISTEMA OPERATIVO INTERFACCE GRAFICHE

IL SISTEMA OPERATIVO IL SISTEMA OPERATIVO INTERFACCE TESTUALI INTERFACCE TESTUALI FUNZIONI DEL SISTEMA OPERATIVO INTERFACCE GRAFICHE IL SISTEMA OPERATIVO Insieme di programmi che opera al di sopra della macchina fisica, mascherandone le caratteristiche e fornendo agli utenti funzionalità di alto livello. PROGRAMMI UTENTE INTERPRETE

Dettagli

REPUBBLICA ITALIANA Regione Siciliana ASSESSORATO BILANCIO E FINANZE Dipartimento Finanze e Credito

REPUBBLICA ITALIANA Regione Siciliana ASSESSORATO BILANCIO E FINANZE Dipartimento Finanze e Credito REPUBBLICA ITALIANA Regione Siciliana ASSESSORATO BILANCIO E FINANZE Dipartimento Finanze e Credito Servizio Informatica Servizio Agevolazioni nelle Operazioni creditizie di garanzia Manuale per la compilazione

Dettagli

La prima applicazione Java. Creazione di oggetti - 1. La prima applicazione Java: schema di esecuzione. Gianpaolo Cugola - Sistemi Informativi in Rete

La prima applicazione Java. Creazione di oggetti - 1. La prima applicazione Java: schema di esecuzione. Gianpaolo Cugola - Sistemi Informativi in Rete La prima applicazione Java Programma MyFirstApplication Il programma visualizza una finestra vuota sullo schermo. Importo il package delle classi usate nel seguito. Dichiaro la classe MyFirstApplication

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

Lezione 8. La macchina universale

Lezione 8. La macchina universale Lezione 8 Algoritmi La macchina universale Un elaboratore o computer è una macchina digitale, elettronica, automatica capace di effettuare trasformazioni o elaborazioni su i dati digitale= l informazione

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

Diagrammi di Interazione

Diagrammi di Interazione Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Diagrammi di Interazione Definizioni Diagrammi di Interazione una interazione specifica i dettagli

Dettagli

Sequence Diagram e Collaboration Diagram

Sequence Diagram e Collaboration Diagram Sequence Diagram e Collaboration Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Sommario Interaction

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

Il problema. ! Si chiede di sviluppare un applicazione per la

Il problema. ! Si chiede di sviluppare un applicazione per la Il problema! Si chiede di sviluppare un applicazione per la gestione del sistema bibliotecario universitario. La soluzione deve implementare le operazioni basilari per la gestione della biblioteca ed inoltre

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

Le Infrastrutture Software ed il Sistema Operativo

Le Infrastrutture Software ed il Sistema Operativo Le Infrastrutture Software ed il Sistema Operativo Corso di Informatica CdL: Chimica Claudia d'amato claudia.damato@di.uniba.it Il Sistema Operativo (S0) (Inf.) E' l'insieme dei programmi che consentono

Dettagli

Bisanzio Software Srl AMICA IMPORTA. Come importare dati nella famiglia di prodotti AMICA GESTIONALE (www.amicagestionale.it)

Bisanzio Software Srl AMICA IMPORTA. Come importare dati nella famiglia di prodotti AMICA GESTIONALE (www.amicagestionale.it) Bisanzio Software Srl AMICA IMPORTA Come importare dati nella famiglia di prodotti AMICA GESTIONALE (www.amicagestionale.it) Nicola Iarocci 10/05/2010 AMICA IMPORTA Stato del documento: BOZZA Stato del

Dettagli

Lo Studio di Fattibilità

Lo Studio di Fattibilità Lo Studio di Fattibilità Massimo Mecella Dipartimento di Informatica e Sistemistica Università di Roma La Sapienza Definizione Insieme di informazioni considerate necessarie alla decisione sull investimento

Dettagli

UML e la progettazione di e-learning

UML e la progettazione di e-learning UML e la progettazione di e-learning Perché UML? UML (Unified Modeling Language, letteralmente: Linguaggio Unificato di Modellazione) viene spesso confuso come una metodologia per analizzare e progettare

Dettagli

COS È UN LINGUAGGIO? LINGUAGGI DI ALTO LIVELLO LA NOZIONE DI LINGUAGGIO LINGUAGGIO & PROGRAMMA

COS È UN LINGUAGGIO? LINGUAGGI DI ALTO LIVELLO LA NOZIONE DI LINGUAGGIO LINGUAGGIO & PROGRAMMA LINGUAGGI DI ALTO LIVELLO Si basano su una macchina virtuale le cui mosse non sono quelle della macchina hardware COS È UN LINGUAGGIO? Un linguaggio è un insieme di parole e di metodi di combinazione delle

Dettagli

Il marketing dei servizi

Il marketing dei servizi Il marketing dei servizi Il gap 2: la progettazione del servizio e gli standard operativi visibili e misurabili dai clienti 22 P f ROBERTO PAPA GAP 2: il gap di progettazione del servizio Il secondo gap

Dettagli