Anteprima
Vedrai una selezione di 9 pagine su 40
Requisiti software Pag. 1 Requisiti software Pag. 2
Anteprima di 9 pagg. su 40.
Scarica il documento per vederlo tutto.
Requisiti software Pag. 6
Anteprima di 9 pagg. su 40.
Scarica il documento per vederlo tutto.
Requisiti software Pag. 11
Anteprima di 9 pagg. su 40.
Scarica il documento per vederlo tutto.
Requisiti software Pag. 16
Anteprima di 9 pagg. su 40.
Scarica il documento per vederlo tutto.
Requisiti software Pag. 21
Anteprima di 9 pagg. su 40.
Scarica il documento per vederlo tutto.
Requisiti software Pag. 26
Anteprima di 9 pagg. su 40.
Scarica il documento per vederlo tutto.
Requisiti software Pag. 31
Anteprima di 9 pagg. su 40.
Scarica il documento per vederlo tutto.
Requisiti software Pag. 36
1 su 40
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

SVILUPPO DELL'SRS + ESERCIZIO RISTORANTE - MODELLAZIONE ANALITICA e ANALISI DEI CASI D'USO

Sul terreno tecnico, la realizzazione di software comincia con una serie di operazioni di modellizzazione che conducono a una specifica completa dei requisiti e al progetto che rappresenta il prodotto da realizzare. Il modello analitico, in realtà una famiglia di modelli, è la prima rappresentazione tecnica di un sistema.

La manutenzione dei prodotti dell'analisi deve essere semplice e affrontata con le Specifiche dei requisiti del software. La modellizzazione analitica usa una combinazione di forme grafiche e di testo per rappresentare i requisiti dei dati, delle funzionalità e dei comportamenti in un modo relativamente facile da comprendere e, soprattutto, che agevola la verifica della correttezza, completezza e uniformità. Di esso se ne occupa in ingegnere del software chiamato analista, che realizza il modello utilizzando i.

requisiti individuati tramite richieste del cliente. Per convalidare i requisiti software occorre esaminarli da vari punti di vista. La modellizzazione concettuale rappresenta i requisiti da più punti di vista aumentando così la probabilità di individuare errori, di rilevare inconsistenze e di scoprire omissioni. I requisiti informativi, funzionali e del comportamento vengono modellati utilizzando vari formati grafici. La modellizzazione basata su scenari rappresenta il sistema dal punto di vista dell'utente. La modellizzazione orientata al flusso fornisce un'indicazione del modo in cui gli oggetti-dato vengono trasformati dalle funzioni di elaborazione. La modellizzazione comportamentale rappresenta gli stati del sistema e delle sue classi e l'impatto degli eventi su questi stati. Una volta che sono stati creati i modelli preliminari, questi vengono raffinati e analizzati per stabilirne la chiarezza, completezza e consistenza. Il modello analitico

Il finale viene convalidato da tutti coloro che sono coinvolti nell'attività. Viene prodotta una gran varietà di diagramma, di cui ogni rappresentazione fornisce una descrizione di uno o più elementi del modello. Gli elementi prodotti dalla modellizzazione analitica devono riflettere i bisogni di tutte le figure coinvolte nello sviluppo e rappresentare la base a partire dalla quale può essere condotta la progettazione.

Analisi dei requisiti. L'analisi dei requisiti porta a specificare le caratteristiche operative del software; indica l'interfaccia fra software e gli altri elementi del sistema e stabilisce i vincoli che devono essere considerati dal software. L'analisi dei requisiti consente all'ingegnere software (che in questo ruolo è detto analista o moderatore) di elaborare i requisiti di base definiti durante i precedenti compiti di ingegneria dei requisiti e di costruire modelli che rappresentano gli scenari utente, le

Attività funzionali, le classi dei problemi e le loro relazioni, i comportamenti del sistema e della classe e il flusso dei dati mentre questi vengono trasformati. L'analisi dei requisiti offre al progettista software una rappresentazione delle informazioni, delle funzioni e dei comportamenti che possono essere tradotti in progetti a livello dell'architettura, dell'interfaccia e dei componenti. Infine il modello analitico e le specifiche dei requisiti forniscono allo sviluppatore e al cliente i mezzi per valutare la qualità del risultato una volta che il software è stato realizzato. Durante la modellizzazione analitica, l'ingegnere del software deve principalmente concentrarsi sul "cosa" e sul "come". Quali oggetti vengono manipolati dal sistema? Quali funzioni deve svolgere il sistema? Quali comportamenti deve esibire il sistema? Quali interfacce vengono definite e quali vincoli si

applicano? http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE - FranK 23

Sappiamo che in tale fase però non può essere disponibile una specifica completa dei requisiti. Il cliente non potrebbe essere sicuro esattamente di ciò di cui ha bisogno. Lo sviluppatore può non essere sicuro che un determinato approccio sia corretto dal punto di vista delle funzioni delle prestazioni. Questi elementi fanno propendere per un approccio iterativo all'analisi e alla modellizzazione dei requisiti. L'analista dovrebbe modellare ciò che è noto e utilizzare tale modello come elemento di base per la progettazione dell'incremento software.

Il modello analitico deve raggiungere tre obiettivi fondamentali: 1) descrivere ciò di cui il cliente ha bisogno, 2) stabilire una base per la creazione di un progetto software e 3) definire un insieme di requisiti che possono

essere convalidati una volta che il software sia stato realizzato. Il modello analitico rappresenta un ponte tra la descrizione del sistema e il modello progettuale.

Descrizione del sistema Modello Progettazione analitico concettuale

Regole analitiche empiriche. Ecco alcune regole utili che dovrebbero essere rispettate attentamente quando si crea un modello analitico.

  • Il modello dovrebbe concentrarsi sui requisiti visibili nel dominio del problema o dell'attività. Il livello di astrazione dovrebbe essere relativamente elevato.
  • Ogni elemento del modello analitico dovrebbe contribuire a una comprensione globale dei requisiti software e fornire un punto di vista approfondito sul dominio delle informazioni, sulle funzioni e sul comportamento del sistema.
  • Ricordare le considerazioni sull'infrastruttura e su altri modelli non funzionali fino alla fase di progettazione.
  • Minimizzare l'accoppiamento con il sistema.
  • Assicurarsi che il modello analitico sia adeguato per tutte

Le figure coinvolte nell'attività di sviluppo.

Privilegiare il più possibile la semplicità del modello: non aggiungere diagrammi che non forniscono alcuna informazione aggiuntiva. Non usare forme complesse quando può esserne impiegata una più semplice.

Analisi del dominio. L'analisi del dominio del software prevede l'identificazione, l'analisi e la specifica dei requisiti comuni di un determinato dominio applicativo, per poterli riutilizzare in più processi nell'ambito del dominio applicativo. L'obiettivo dell'analisi del dominio è immediato: trovare o creare le classi analitiche e/o funzioni caratteristiche comuni ampiamente applicabili, in modo da poterle riutilizzare. Il ruolo dell'analista di dominio è quello di scoprire e definire schemi analitici, classi analitiche e informazioni correlate che possano essere utilizzate da più persone che lavorano su applicazioni simili ma non.

necessariamente identiche.http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE - FranK 24

Approcci alla modellazione analitica. Una visione della modellazione analitica, chiamata analisi strutturata, considera i dati e i processi che trasformano i dati come entità distinte. Gli oggetti-dato vengono modellati in modo da definire i loro attributi e le loro relazioni. I processi che manipolano gli oggetti-dato vengono modellati in modo da mostrare come i dati si trasformano a mano a mano che attraversano il sistema.

Un secondo approccio alla modellazione analitica, chiamato analisi orientata agli oggetti, si concentra sulla definizione delle classi e dei modi in cui esse collaborano per rispondere ai requisiti del cliente. I diagrammi UML e il processo unificato sono fondamentalmente orientati agli oggetti.

Gli elementi del modello analitico sono elementi basati su scenari, elementi orientati al flusso,

elementi comportamentali e elementi basati su classi.

La modellazione analitica spesso inizia con la modellazione dei dati. L'ingegnere software o l'analista definisce tutti gli oggetti-dato che verranno elaborati dal sistema, le relazioni esistenti fra tali dati e le altre informazioni pertinenti a queste relazioni.

Oggetti-dato. Un oggetto-dato è la rappresentazione di un'informazione composita (proprietà o attributo) destinata a essere trattata dal software. Per informazione composita si intende un oggetto caratterizzato da un certo numero di proprietà o attributi. Un oggetto-dato può essere una entità esterna, una cosa, un'occorrenza, un'unità organizzativa, un luogo o una struttura. Una "persona" o un "automobile" possono essere considerati oggetti perché sono definiti mediante un insieme di attributi. La descrizione di un oggetto comprende l'oggetto e tutti i suoi attributi.

oggetto-dato comprende solo dati: non si fa alcun riferimento alle operazioni che agiscono su di essi. Esso può essere rappresentato in forma di tabella, con le intestazioni delle colonne corrispondenti ai suoi attributi (rappresentazione tabellare degli oggetti-dato).

Attributi. Gli attributi definiscono le proprietà di un oggetto-dato e servono a tre scopi: 1) dare un nome a un esemplare dell'oggetto; 2) descrivere l'esemplare; 3) rimandare ad altri esemplari di altre tabelle. Uno o più attributi svolgono il ruolo di identificatore (chiave nella ricerca dell'oggetto-dato), ed essi possono essere univoci.

Tra oggetto-dato e classi orientate agli oggetti esistono sostanziali differenze: un oggetto-dato definisce un elemento composito, ovvero un elemento che include una raccolta di elementi (attributi) e vi assegna un nome (il nome dell'oggetto-dato). Una classe orientata agli oggetti incapsula gli attributi dei dati ma include anche le operazioni.

chemanipolano i dati determinati da questi attributi. Inoltre le classi comunicano tra loro scambiandosi messaggi e possono essere organizzate in gerarchie, nonché ereditate.

Le relazioni. Gli oggetti-dato possono essere collegati tra loro in vari modi: si crea un insieme di coppie oggetto-relazione. Si indica graficamente con una freccia che unisce i due diagrammi degli oggetti considerati.

La terna oggetti-dato, attributi e relazioni forma il fondamento per la modellazione dei dati, lo studio del dominio delle informazioni di un problema. Ma non basta sapere solo che un oggetto x sia collegato a un oggetto y, ma anche a quante occorrenze dell'oggetto y sono collegate le occorrenze dell'oggetto x. Si parla così di cardinalità.

Il modello dei dati deve poter rappresentare il numero di occorrenze degli oggetti in una data relazione. La cardinalità definisce il numero di occorrenze di un oggetto che possono essere collegate al numero di occorrenze di un altro oggetto.

el database utilizzano le cardinalità per definire le relazioni tra le tabelle. La relazione uno a uno (1:1) indica che ogni record nella tabella A può essere associato a un solo record nella tabella B e viceversa. Ad esempio, nella tabella "Utenti" potrebbe esserci una colonna "ID" che è univoca per ogni utente e nella tabella "Dettagli Utente" potrebbe esserci una colonna "ID Utente" che fa riferimento all'ID dell'utente corrispondente. La relazione uno a molti (1:N) indica che ogni record nella tabella A può essere associato a uno o più record nella tabella B, ma ogni record nella tabella B può essere associato a un solo record nella tabella A. Ad esempio, nella tabella "Categorie" potrebbe esserci una colonna "ID" che è univoca per ogni categoria e nella tabella "Prodotti" potrebbe esserci una colonna "ID Categoria" che fa riferimento all'ID della categoria corrispondente. La relazione molti a molti (N:M) indica che ogni record nella tabella A può essere associato a uno o più record nella tabella B e viceversa. Questo tipo di relazione richiede l'utilizzo di una tabella di collegamento per stabilire le associazioni. Ad esempio, nella tabella "Studenti" potrebbe esserci una colonna "ID" che è univoca per ogni studente e nella tabella "Corsi" potrebbe esserci una colonna "ID" che è univoca per ogni corso. La tabella di collegamento "StudentiCorsi" potrebbe avere due colonne "ID Studente" e "ID Corso" per stabilire le associazioni tra gli studenti e i corsi. Le cardinalità definiscono quindi il tipo di relazione tra le tabelle e il massimo numero di oggetti che possono partecipare a quella relazione.
Dettagli
Publisher
A.A. 2012-2013
40 pagine
SSD Scienze matematiche e informatiche INF/01 Informatica

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher cecilialll di informazioni apprese con la frequenza delle lezioni di Fondamenti di informatica e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli studi di Napoli Federico II o del prof Fassolino Rita.