Modelli di Sistema

Corso di Laurea Specialistica in Ingegneria Informatica
Corso di Ingegneria del Software
Modellazione di sistema
E. TINELLI
A. A. 2008 - 2009
Contenuti
• Approcci di analisi
• Linguaggi di specifica
• Modelli di analisi
–
–
–
–
–
Modelli
Modelli
Modelli
Modelli
Modelli
contestuali
comportamentali
di informazione
a oggetti
strutturati
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
2
Approcci all’Analisi
• Approccio Informale
– nessun modello del sistema viene costruito (uso di un linguaggio
informale)
– la raccolta delle informazioni avviene attraverso una serie di riunioni
tra gli utenti/committenti ed analisti, l’uso di questionari, studio di
documentazione esistente, …
– si procede attraverso la formulazione e il raffinamento di vari
documenti di SRS che sono sottoposti alla convalida nell’ambito di
opportuni meeting
• Approccio basato su modelli concettuali
– produce rappresentazioni del dominio applicativo e del sistema
basate su linguaggi formali o semi-formali inseriti nel documento
• Approccio basato sulla prototipazione
– il problema viene analizzato ed i requisiti sono compresi grazie
all’uso di un prototipo del sistema da parte di cliente ed utenti
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
3
Alcuni approcci basati sui modelli concettuali
• Analisi Strutturata
– basata sull’uso di Data Flow Diagrams (DFD) e Dizionario dei
Dati
– l’analisi del problema viene eseguita usando l’approccio della
decomposizione delle funzioni
– i dati e le relative relazioni sono modellati con linguaggi diversi
(es. modello Entità-Relazioni)
• Analisi Object-Oriented
– l’analisi del problema viene eseguita usando l’approccio della
decomposizione in oggetti (entità/ concetti del dominio del
problema)
– uso di linguaggi di modellazione, es. UML
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
4
Data Flow Diagram (DFD)
• Rappresenta le trasformazioni che i dati subiscono nel loro
flusso all’interno del sistema
• Ogni sistema di elaborazione effettua una trasformazione di
dati di ingresso in dati di uscita
• Permette anche di descrivere processi di business
Un produttore o consumatore di dati
(persone, dispositivi, sensori)
Un elaboratore di dati
(trasforma dati di input in dati di output)
Il flusso dati in un sistema inizia come input e
termina come output
I dati devo essere spesso memorizzati per
elaborazioni successive
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
5
DFD – Esempi
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
6
Dizionario dei dati
• Lista ordinata alfabeticamente dei nomi inclusi nei modelli del sistema
(nomi di entità, di relazioni, di attributi, di servizi, ecc.)
• Possibile struttura di un dizionario:
Nome
Descrizione
Tipo
Data
Composizione Creatore …
• Vantaggio – quando si sviluppa un grande modello di sistema in cui
intervengono molte persone è possibile che vengano usati gli stessi
nomi (strumenti CASE per verificare l’unicità del nome)
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
7
Tecniche di specifica
• Le tecniche si suddividono
– rispetto al grado di formalità della descrizione (del rispettivo
linguaggio). La formalità indica il rigore con cui sono definite
la sintassi e la semantica del linguaggio.
– rispetto a cosa descrivono del sistema (il loro stile) ossia
quale aspetto del sistema è più facile descrivere utilizzando il
linguaggio (comportamento o proprietà)
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
8
Grado di Formalità
• Notazioni informali: le specifiche del sistema sono descritte in
linguaggio naturale. Spesso usato perché è facilmente comprensibile
dal committente ma è una possibile fonte di ambiguità
• Notazioni formali: la specifica è un oggetto formale rappresentata
in una notazione logico-matematica definita in modo rigoroso sul
piano sintattico e semantico. Aumenta le capacità di astrazione ed
elimina le ambiguità. Consente di ragionare su e verificare proprietà,
anche con strumenti (semi)automatici che supportano quel
linguaggio.
• Notazioni semi-formali: immediatamente comprensibili utilizzano
notazioni grafiche accompagnate da descrizioni in linguaggio
naturale; riducono le interpretazioni ambigue; i modelli semiformali
sono allo stato dell’arte i più flessibili ed i più usati
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
9
Stili di specifica
• Stile descrittivo
– definisce le proprietà desiderate del sistema con un elevato grado di
astrazione cioè non descrive una possibile realizzazione del sistema
– E’ più difficile capire come si comporta il sistema descritto
– E’ più facile fare ragionamenti (es. dimostrare formalmente che vale una
certa proprietà, modificare la descrizione perché valga una proprietà)
• Stile operazionale:
– definisce il comportamento desiderato del sistema. Si descrive il
comportamento atteso mediante una macchina astratta suggerendone una
possibile implemementazione
– Pro
• E’ facilmente eseguibile
• E’ facile costruire un prototipo e verificarne l’aderenza alla descrizione (medesimo
comportamento)
– Contro
• Spinge decisamente verso una certa implementazione
• E’ più difficile risalire alle proprietà del sistema e provarle
• Specifica mista
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
10
Stili di specifica e Linguaggi
• Specifica operazionale:
– Diagrammi del Flusso Dati (DFD)
– Macchine a Stati Finiti (FSM) - sono molto usate per verificare formalmente
le proprietà dei sistemi. Una FSM si trova sempre in un solo stato e permette
di specificare soltanto uno stato successivo per una stessa azione.
– Reti di Petri (PN) - formalismo ideato negli anni 60 per modellare sistemi
concorrenti si focalizza sul controllo. Formalmente sono definite da una
quadrupla <P,T,F,W> mentre con token si indica lo stato della rete.
• Specifica descrittiva:
– Diagrammi Entità- Relazione (ER)
– Specifiche basate sulla Logica – es. TRIO linguaggio di specifica sviluppato
fine anni 80 esteso con costrutti orientati agli oggetti (TRIO+) è una logica
temporale del primo ordine, con una nozione metrica di tempo.
• Specifica mista:
• Linguaggio Z - fornisce un modello (una macchina astratta) e poi
descrive, facendo uso di logica, il meccanismo con cui funziona questa
macchina astratta.
• UML
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
11
I linguaggi di specifica - Riepilogo
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
12
Che cosa è un modello?
• Per modello del sistema si intende una rappresentazione
astratta del sistema che facilita la comprensione delle
proprietà del sistema e delle sue caratteristiche di
funzionamento, prima che il sistema venga costruito
• Per descrivere completamente un sistema è necessario
costruire vari modelli che rappresentino il sistema da vari
punti di vista (informazioni, funzioni e comportamento
dinamico)
• Si possono sviluppare diversi modelli per rappresentare il
sistema secondo diverse prospettive (prospettiva esterna,
prospettiva comportamentale, prospettiva strutturale)
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
13
Modello contestuale
• Durante la fase di deduzione ed analisi dei requisiti è bene
fissare i confini del sistema (distinguere cosa è il sistema e
cosa è l’ambiente del sistema)
• Es. per BiblioSYS bisogna decidere se i vari database delle
biblioteche fanno parte del sistema o no
• Un modello contestuale è generalmente costituito da un
semplice modello architetturale di alto livello espresso come
diagramma a blocchi: ogni rettangolo è un sottosistema e le
linee rappresentano le relazioni tra i sottosistemi
• Un modello architetturale descrive l’ambiente di un sistema
e non le relazioni con altri sistemi Æ utilizzare altri modelli
quali modelli di processo o modelli di data-flow
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
14
Modello comportamentale
• È utilizzato per descrivere il comportamento generale del
sistema e ne rappresenta gli aspetti funzionali:
– Data-flow diagram – se si vuole mettere in evidenza come
il sistema elabora i dati secondo una prospettiva funzionale
in cui ogni trasformazione rappresenta una singola funzione
o processo
– Macchina a stati finiti – se si vuole descrivere come il
sistema reagisce ad eventi esterni o interni mostrando gli
stati del sistema e gli eventi che causano la transizione da
uno stato all’altro e non i dati scambiati (usato per sistemi
real-time generalmente gestiti da stimoli esterni)
– Diagrammi UML – per rappresentare gli aspetti funzionali
del sistema (use case diagram, activity diagram, interaction
diagram)
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
15
Modello di informazione
• È utilizzato per definire la forma logica dei dati elaborati dal
sistema (modellazione semantica dei dati)
• Si possono utilizzare i modelli Entità-Relazioni (ER) – gli
schemi logici ottenuti da tali modelli sono naturalmente in
terza forma normale
• Database a oggetti
• Rappresentazione UML di un modello ER – entità sono
classi di oggetti semplificate e gli attributi sono gli attributi
delle classi
• Diagramma delle dipendenze – produce schemi logici in
quinta forma normale
• I modelli di informazione mancano di dettaglio e si
dovrebbero mantenere descrizioni più dettagliate su entità,
attributi e relazioni in un Dizionario dei Dati
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
16
Diagramma delle dipendenze – convenzioni grafiche
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
17
Tipi di bolle
• Target – è la bolla a cui arriva una dipendenza singola
• Chiave finale – è la bolla a cui arriva una dipendenza
multipla e da cui non parte alcuna dipendenza
• Chiave primaria - è la bolla da cui dipende la bolla Target,
se la dipendenza è singola, oppure la bolla Finale, se la
dipendenza è multipla
• Chiave uplink – è la bolla da cui parte una dipendenza
multipla per una chiave primaria o per un’altra uplink
• Bolla doppia, tripla, ecc. – questo tipo di bolla serve a
rappresentare diverse dipendenze tra i dati di uno stesso
diagramma
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
18
Esempio di diagramma delle dipendenze
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
19
Modello a oggetti
• Comunemente utilizzato per l’intero processo di sviluppo
software
• Una classe è un’astrazione da un insieme di oggetti che
identifica gli attributi comuni ed i servizi/operazioni fornite
da ogni oggetto. Gli oggetti sono istanze della classe ossia
entità eseguibili con gli attributi ed i servizi della classe
relativa.
• Il processo di analisi per identificare gli oggetti e le classi è
riconosciuto come una delle più difficili aree dello sviluppo
orientato agli oggetti
• Diversi metodi di analisi orientata agli oggetti furono
proposti negli anni ’90 Æ integrati per produrre un unico
modello: Unified Process
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
20
Modello strutturato
•
•
•
•
È un metodo sistematico di produrre modelli di un sistema che generalmente ha
il proprio insieme di modelli “preferito” (es. UP)
Definiscono un processo da cui derivare i modelli ed un insieme di linee guida
Sono disponibili strumenti CASE che supportano l’editing del modello, la
generazione di codice e report e alcune proprietà di verifica
Punti deboli: non forniscono adeguato supporto per i requisiti NON funzionali,
sono indiscriminati, possono produrre troppa documentazione e troppo
dettagliata
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
21