3-modellazione oggetti spaz

Architettura dei Database Territoriali
Pr. R. Laurini
III – STRUMENTI PER LA
MODELLAZIONE DEGLI
OGGETTI SPAZIALI
Capitolo 3°
STRUMENTI PER LA
MODELLAZIONE DEGLI
OGGETTI SPAZIALI
3.1 – Dati alfanumerici e
multimediali
• Alfanumerico
– intero, reale, catena di caratteri, booleani
• Multimediale
–
–
–
–
–
segnali, immagini, disegni,
immagini animate,
audiovisivi,
documenti, musica
Ecc.
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
•
•
•
•
•
•
•
•
3.1 – Dati alfanumerici e multimediali
3.2 – Riassunto sulle strutture dati
3.3 – Livelli di progettazione - ANSI SPARC
3.4 – Formalismo entità-associazioni
3.5 – Formalismo con pittogrammi e icone
3.6 – Passaggio dal concettuale al relazionale
3.7 – UML
3.8 – Conclusioni
3.2 – Riassunto sulle strutture dati
•
•
•
•
•
•
Tabella
Lista
Anello
Albero binario
Altre strutture
Indice
1
Architettura dei Database Territoriali
Pr. R. Laurini
Strutture dati
• Dati elementari
Tabella
• Vettore = tabella a 1 dimensione
– interi, reali, booleani, caratteri, ecc.
• Tabella a n dimensioni
• Struttura dati = parecchi dati legati insieme
• Esempi: un vettore, una tabella, ecc.
Vettore (tabella a 1 dim.)
Provincie
Agrigento
Alessandria
Ancona
Aosta
Arezzo
Ascoli Piceno
Asti
Avelino
Bari
Belluno
Benevento
Bergamo
Bologna
Brescia
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
Tabella a 2 dimensioni
Dj
Oi
Tij
Esempio: Tij = numero delle persone di origine i andando alla destinazione j
2
Architettura dei Database Territoriali
Pr. R. Laurini
Lista
Anello
Ingresso
Svizzera
Ingresso
Germania
Spagna
Grecia
Francia
Belgio
Irlanda
Danimarca
Italia
Danimarca
Belgio
Lussemburgo
Paesi Bassi
Portogallo
Spagna
Albero binario
Albero binario per classificazione
GR
Io
vvvv
Nonna
vvvvv
Nonnetto
vvvvv
Nonnetta
vvvvvv
LUX
E
Mamma
Papà
Nonno
..............
vvvvvv
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
D
B
I
F
DK
GB
NL
IRL
P
3
Architettura dei Database Territoriali
Pr. R. Laurini
Alberi n-ari
Indice
• Elenco
• Acceleratore d’accesso
• Senza indice:
Giulio
Gustavo
Ann
Ursula
Francesca
Maria
Giacomo
Antonio
– scansione sequenziale di tutto il DB
– costoso in termine di tempo
Luigi
• Necessità di struttura dati e procedure di
accesso adattate
Carlo
Indicizzazione
Gerarchia di indici
Indice livello 1
Indice livello 2
1
Chiavi
Indirizzi
….
…..
…..
….
…..
……
…...
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
05 5
11 6
22 7
5
33 8
42 9
59 10
6
68 11
77 12
89 15
7
13 26
15 27
22 28
...
15
79 44
85 45
89 46
01 20
03 21
05 22
Indice livello 3
2
22
1
59
2
89
3
3
...
07 23
09 24
11 25
Dati
aaaa
bbbb
cccc
dddd
Blocco
eeee
gggg
hhhh
kkkk
Blocco
...
4
Architettura dei Database Territoriali
Pr. R. Laurini
3.3 – Livelli di progettazione ANSI SPARC
Tempi di risposta
• Ipotizziamo n record
• Metodo per la progettazione dei sistemi
informativi
• Senza indice (scansione sequenziale)
• tm = n/2
• Con indici (scansione dicotomica)
• tm = log2(n)
• Separazione dei dati dai trattamenti
• Metodo MERISE
MONDO REALE
Modello
ANSI SPARC
Modello
esterno 1
Modello
esterno 2
Modello concettuale (1/2)
Modello
esterno 3
Modello
esterno n
Modello
concettuale
• Biglietto da visita del DB
• Modello di una porzione del mondo reale
(mini-mondo)
• Concettuale
– Fatto con concetti chiari
– Base della concezione del DB
Modello
logico
Modello
interno
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
5
Architettura dei Database Territoriali
Pr. R. Laurini
Modello concettuale (2/2)
• Caratteristiche di un buon modello
concettuale
– Espressività
– Semplicità
– Minimalità
– Formalità
Modello logico
• Utilizzando un formalismo matematico
preciso
• Ad esempio: modello relazionale
Formalismo entità-associazione
Modello interno
•
•
•
•
Detto anche fisico
Fatto con strutture dati
Importanza degli indici
Performanza
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
Esempio
Mondo
reale
Modello
concettuale
Modello
logico
Nodo
x
y
Realtà
Modello
Schema
Concetto di strada
nella mente
dei cittadini
Classificazione: strada
Identificazione: nome
Geometria: arco
Tabella con 3 colonne
Per nodi: intero
Per coordinate : reale
6
Architettura dei Database Territoriali
Pr. R. Laurini
Esempio di modello di flussi
3.4 – Formalismo
entità-associazione
Amministrazione
del
Catasto
Mappe
catastali
• Divisione dell'entità in domini
• Analisi dei flussi d'informazioni tra gli
attori interni ed esterni
• Modello concettuale
Ufficio
della
Ricomposizione
Fondiaria
Consultazione
Modello entità-associazione
CARDINALITA
ASSOCIAZIONE
Persona
- nome
- codice fiscale
- data di nascità
0-n
Possesso
- data di
acquisito
1-n
Particella
- numero
- superficie
ATTRIBUTI
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
Richiesta
di
ricomposizione
Informazioni
Litterali
Proprietari
CLASSE D'ENTITA
Attore
della
Ricomposizione
Ministero
Comuni, ecc.)
Informazione
sulle
ipoteche
Ufficio
delle Ipoteche
Modello entità-associazione
•
•
•
•
•
•
•
detto anche entità-relazione
ISO TC 97 SC5 WG3 1982
individuare gli identificatori (chiavi)
chiave
chiave discrimante
chiave stabile nel tempo
chiave minimale
7
Architettura dei Database Territoriali
Pr. R. Laurini
Concetti
•
•
•
•
•
•
•
Esempio
entità
classe d’entità
attributi
identificatore
associazione
cardinalità (i-j ; k-l)
vincoli d’integrità
Città
- nome
- sindaco
1-n
• Associazioni one-to-many
• Associazioni many-to-one
• Associazioni many-to-many
Avere2
1-1
1-1
Strada
Isolato
Limite
- numero
3-n
1-n
- numero
- nome
1-n
Avere3
1-1
Particella
- numero
- superficie
3.5 – Formalismo con
pittogrammi e icone
Associazioni
• Spesso con attributi
1-n
Avere1
• Piccolo disegno (simbolo grafico)
rappresentando un tipo geometrico
• Pittogrammi
Punto
• Uso
Linea Superficie
Volume
Provincia
- nome
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
8
Architettura dei Database Territoriali
Pr. R. Laurini
Altri esempi
Modello concettuale con icone
Città
Parcheggio
Pittogramma semplice
- ecc...
1-n
Localizzare
1-n
Particella
Strada
1-n
Limite
0-n
1-n
Contenire
Città
Pittogramma alternativo
1-1
Fabbricato
Proprietario
- ecc...
Possesso
1-n
Con pittogrammi e icone
Città
Nome
Popolazione
1..*
1-n
Pittogrammi e icone
• Facilitano la comprensione
1-n
1-1
Particella
Strada
Nome
Tipo
Direzione
Limite
2-n
3-n
Nome
Indirizzo
• Esistono pittogrammi
– temporali
– spazio-temporali
1-n
• Uso delle icone per le interfaccie visuali
0-1
A Proprietario
N°Proprietario
Nome
Data di nascità
1-n
1-n
Casa
Indirizzo
Superficie
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
9
Architettura dei Database Territoriali
Pr. R. Laurini
3.6 – Passaggio dal concettuale
al relazionale
Entità
• Prima fase di trasformazione
Particella
– Ogni entità una relazione
– Ogni associazione una relazione
- N° di particella
- superficie
• Seconda fase
– Modifiche
PARTICELLA (N_Particella, Superficie)
Associazione many-to-many
Particella
- N_particella
- superficie
Proprietario
1-n
Possesso 1
-Data-compr
1-n
- N_proprietario
- indirizzo
Associazioni one-to-many
Proprietario
- N° di proprietario
1-n
- indirizzo
Veicolo
Possesso-2
-Data-compr
1-1
-Targa
- Modello
POSSESSO-1 (N_Particella, N_Proprietario, Data-compr)
VEICOLO(Targa, modello, Data-comp)
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
10
Architettura dei Database Territoriali
Pr. R. Laurini
Esempio
Entità e associazioni
• Entità
• "Una ditta di distribuzione desidera
organizzare la gestione degli ordini in
corso sotta la forma di un data-base. Un
cliente può avere parecchi ordini in corso e
ciascun di loro può indicare parecchi
articoli".
Modello concettuale
– articoli
– clienti
– ordini
• Associazioni
– clienti-ordini
– ordini-articoli
Relazioni
CLIENTE (No-cliente, nome, indirizzo,CF)
Cliente
-No-cliente
-nome
-indirizzo
-CF
1-n
Ordine
Articolo
-No-ordine
-No-articolo
-quantità-Sto
-prezzo
1-1
1-n
0-n
Ordina
Contiene
- data
-quantità-ordinata
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
ORDINE (No-ordine, data-ordine)
ARTICOLO (No-articolo, qtàsto, prezzo)
CONTIENE (No-ordine, No-articolo,
Qtàordinata)
11
Architettura dei Database Territoriali
Pr. R. Laurini
3.7 – UML
• UML = Unified Modeling Language
• OMG = Object Management Group
• Metodo di disegno, soprattutto per il
software engineering
• Versione 2.0
UML
• UML è un linguaggio grafico.
• Modello: è l'astrazione di un problema.
• Unificato: rappresenta uno standard.
• Linguaggio: insieme di simboli con un
vocabolario ed una grammatica, strumento per la
comunicazione.
http://xoomer.alice.it/giovanni.cocco/guide/guidaUML/guidaUML.htm
Vantaggi dell'UML
Documentazione Ufficiale
• UML 2.0 Superstructure:
• La documentazione del sistema software prima che venga sviluppato.
– La superstruttura definisce sei diagrammi struttura, tre diagrammi
comportamento, quattro diagrammi di interazione e i vari elementi
compresi in essi.
• Lo schema preciso ed organico del sistema semplifica la scrittura del
codice e semplifica il riutilizzo del codice.
• UML 2.0 Infrastructure:
• Migliora la comunicazione fra tutte le persone coinvolte nello
sviluppo.
• UML 2.0 Object Constraint Language (OCL):
• Permette a tutti i componenti del team di avere un idea complessiva di
tutto il sistema.
• UML 2.0 Diagram Interchange:
• Semplifica il mantenimento del sistema.
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
– L'infrastruttura definisce le classi base di fondamento per UML ma anche
per altre specifiche OMG.
– Permette di settare le pre-condizioni, le post-condizioni, le invarianti e
altre condizioni.
– Specifiche che estendono il metamodello di UML con un pacchetto
supplementare per informazione orientata ai grafici, permettendo lo
scambio, la memorizzazione e la visualizzazione cosi come erano in
origine.
12
Architettura dei Database Territoriali
Pr. R. Laurini
• Object Diagram
COMPONENTI UML
•
•
•
•
•
•
•
•
•
Object Diagram
Class Diagram
Use Case Diagram (Diagramma dei Casi d'Uso)
Sequence Diagram (Diagramma di sequenza)
Collaboration Diagram (Diagramma delle collaborazioni)
State Diagram (Diagramma di stato)
Activity Diagram (Diagramma delle attività)
Component Diagram (Diagramma dei componenti)
Deployment Diagram (Diagramma di sviluppo)
• Sequence Diagram (Diagramma di sequenza)
– definisce le interazioni tra gli oggetti in funzione del
tempo.
• Collaboration Diagram (Diagramma delle
collaborazioni)
– serve a descrivere la cooperazione tra le varie
componenti di un sistema. Ponendo l'accento su "quali"
oggetti partecipano ad una data interazione.
• State Diagram (Diagramma di stato)
– definisce lo stato in un dato momento di un sistema e il
suo evolvere(start state, end state) al trascorrere del
tempo
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
– rappresenta una singola classe.
• Class Diagram
– è il diagramma che rappresenta le classi nel senso OOP.
Quindi le classi con attributi, metodi e le loro relazioni.
• Use Case Diagram (Diagramma dei Casi d'Uso)
– è la descrizione del comportamento del sistema dal
punto di vista dell'utente (detto actor va inteso in senso
generale potrebbe anche essere un altro sistema che
interagisce con l'Use Case). Deve specificare i requisiti
del sistema e cosa questo deve fare.
• Activity Diagram (Diagramma delle attività)
– rappresenta la catena ben definita delle azioni(attività)
interne ad un Use Case o ad un Oggetto.
• Component Diagram (Diagramma dei
componenti)
– il component diagram mostra le varie componenti di un
sistema e le loro dipendenze. Si può usare anche per
rappresentare su quale componente software lavora
ogni persona del team. A differenza dei precedenti non
sono diagrammi concettuali ma descrivono componenti
fisiche del sistema.
• Deployment Diagram (Diagramma di sviluppo)
– rappresenta la logistica e le caratteristiche del sistema.
Macchine coinvolte, le caratteristiche, il software
installato e altro...
13
Architettura dei Database Territoriali
Pr. R. Laurini
Esempio diagramma di oggetti
Diagramma di classe
• Nome della classe
• Attributi
• Metodi
Classi ed oggetti
Classi
Oggetti
BankAccount
jimsAccount:BankAccount
-
count:int = 0
number: int
Owner: String
balance double = 0
+
+
+
+
+
+
create(aNumber:int)
incrementCount():void
getCount():int
deposit(d:int):boolean
withdraw(w:int):boolean
setOwner(n:String):void
getOwner(): String
number:int = 1234567
Owner:String = “Jim Arlow”
balance double = 300,00
Nome e attributi
• Nome della classe
– Deve essere scritto con l'iniziale maiuscola. Se
composto da più parole si usa la notazione Pascal
(NomeDellaMiaClasse).
• Attributi della classe
– Ogni classe può avere zero o più attributi che sono le
sue proprietà. Il nome dell'attributo va scritto con la
notazione a Cammello (nomeDellAttributo, notare la
differenza di notazione rispetto ai nomi delle classi).
Agli attributi si può associare un tipo e un valore di
default. Con la sintassi:
visibilitàAttributo nomeAttributo : TipoAttributo = ValoreDefault
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
14
Architettura dei Database Territoriali
Visibilità
• Publico +
– i metodi e gli attributi della classe possono essere usati
da tutte le altre classi.
• Protetto #
– i metodi e gli attributi della classe possono essere usati
da tutte le classe che derivano dalla classe originale
(ereditarietà).
• Privato – i metodi e gli attributi della classe possono essere usati
solo dalla classe stessa dove sono definiti.
Constraint
Pr. R. Laurini
Metodi della classe
• I metodi non sono altro che le azioni che quella
classe può compiere. Il loro nome viene scritto
con la notazione a cammello come per gli attributi
(nomeDelMetodo). Possono essere caratterizzati
da ulteriori informazioni come parametri, il tipo
dei parametri e il tipo del valore restituito se si
tratta di funzioni. La sintassi per i metodi è:
visibilità nomeMetodo (listaParametri) : tipoRestituito {stringaProprietà}.
Le associazioni
• definisce una o più regole che la classe è
tenuta a rispettare. Per tutti quei casi in cui
non è possibile farlo ad esempio con
associazioni o attributi. Si definiscono
inserendo del testo racchiuso tra parentesi
graffe. UML lascia piena libertà su cosa
deve essere il testo.
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
15
Architettura dei Database Territoriali
Pr. R. Laurini
Generalizzazioni
• Una classe può ereditare attributi e metodi da un'altra
classe che viene detta classe padre (o super classe). Alle
clasi figlie possono poi essere aggiunti attributi e metodi
propri della particolare classe. I metodi delle classi figlie
possono anche sovrascrivere i metodi della superclasse.
Esempio di generalizzazione
Shape
draw(g:Graphics)
getArea(): int
getBoundingArea():int
Square
Circle
draw(g:Graphics)
getArea(): int
Aggregazione e composizione
Aggregazione
draw(g:Graphics)
getArea(): int
Esempi
Composizione
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
16
Architettura dei Database Territoriali
Interfacce e realizzazioni
Pr. R. Laurini
Esempio diagramma di classe
• Un interfaccia è una classe che offre i suoi metodi ad altre
classi. A differenza delle classi normali non ha quindi degli
attributi. Il collegamento tra una classe e una interfaccia si
chiama realizzazione ed è rappresentato da una freccia con
linea tratteggiata dalla classe all'interfaccia.
USE CASE DIAGRAM
• Rappresenta ciò che il sistema fa dal punto di vista di un osservatore
esterno. A differenza del Class Diagram che da una visione statica del
sistema lo Use Case Diagram permette di avere una visione del sistema
nel tempo. Si tratta quindi di una descrizione dinamica.
• Ogni Use Case rappresenta una particolare compito che il nostro
sistema dovrà assolvere per soddisfare le richieste dei clienti. Un Use
Case rappresenta diversi scenari che riguardano l'utilizzo del sistema.
Ognuno degli scenari descrive una sequenza di eventi.
• La sequenza degli eventi viene iniziata da quello che si chiama Actor
(può essere una persona, del hardware, un altro sistema o il passare del
tempo stesso). La catena di eventi porta ad un risultato che può essere
destinato all'actor che le ha dato il via oppure a un altro actor.
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
• Uno scenario è una sequenza di passi che descrivono
l'interazione fra un utente e il sistema. Un Use Case è dato
da un insieme di scenari che condividono lo stesso scopo
per l'utente.
• Per individuare gli Use Case si può procedere
individuando tutti gli eventi esterni a cui il sistema deve
reagire.
• Use Case Diagram sono utili in tre aree: definizione i
requisiti del sistema, realizzazione dei test per ogni Use
Case e nella comunicazione con il cliente che risulta
semplificata dal loro utilizzo.
• Gli Use Case non devono essere in realtà molto dettagliati.
La quantità di testo deve essere sufficiente perché l'utente
capisca l'idea di base e il programmatore possa farsi un
idea di cosa ci sarà dietro.
17
Architettura dei Database Territoriali
Pr. R. Laurini
Simbolismo
Actor1
•
•
•
•
•
Esempio diagrammi d’uso
Actor2
L'actor che fa iniziare la sequenza
Le Pre-condizioni dello Use Case
Le diverse sottosequenze dello scenario
Le Post-condizioni dello scenario
L'actor che riceve "l'uscita"' dello Use Case
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
18
Architettura dei Database Territoriali
SEQUENCE DIAGRAMS
Pr. R. Laurini
Simbolismo
• Sequence Diagram è uno dei diagrammi di interazione.
• La scopo è quello di definire le interazioni tra gli oggetti in
funzione del tempo. Per realizzare quindi tale
rappresentazione sono necessari il tempo che viene
rappresentato come evoluzione lungo l'asse verticale, gli
oggetti (rappresentati come rettangoli), e i messaggi
(rappresentati con delle frecce).
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
19
Architettura dei Database Territoriali
Pr. R. Laurini
Quattro i tipi di messaggi
• ricorsivo
– quando un oggetto manda un messaggio a stesso.Rappresentato da una
freccia che inizia e finisce sulla lifeline dello stesso oggetto.
• simple
– messaggio da un oggetto ad un altro che rappresenta il passaggio di
controllo da un oggetto ad un altro. rappresentato da una normale freccia
con punta a triangolo aperto ( -> ).
• synchronous
– implica che il mittente del messaggio ottenga una risposta dal destinatario
del suo messaggio prima di proseguire con altre azioni. Si rappresenta con
una freccia con punta a triangolo pieno.
• asynchronous
– l'oggetto mittente non deve aspettare alcuna risposta dal destinatario prima
di proseguire con le successive operazioni. Un messaggio asincrono può
creare un nuovo thread (punta quindi ad una attivazione), creare un nuovo
oggetto, inviare un messaggio (cioè comunicare con un oggetto già attivo).
COLLABORATION DIAGRAMS
Simbolismo
• Il Collaboration Diagram di un sistema
rappresenta le stesse informazioni del
Sequence Diagram. Solo che mentre nel
Sequence Diagram la rappresentazione è in
funzione del tempo nel Collaboration
Diagram la rappresentazione è in funzione
del ruolo dei messaggi che gli oggetti si
scambiano.
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
20
Architettura dei Database Territoriali
Pr. R. Laurini
STATE DIAGRAM
• Gli State Diagram servono a descrivere
l'evoluzione nel tempo di un oggetto del nostro
sistema.
• Ogni State Diagram si riferisce ad un oggetto
particolare del sistema. Descrive quindi tutti i suoi
possibili stati e come questo passi da uno all'altro
in conseguenza degli eventi che lo raggiungono.
– nome dello stato
– variabili di stato
– attivita dello stato
Simbolismo
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
Esempio
21
Architettura dei Database Territoriali
ACTIVITY DIAGRAMS
Pr. R. Laurini
Simbolismo
• Rappresenta la sequenza delle attività. Supporta
comportamenti condizionali e attività parallele. E'
una variante dello State Diagram.
• L'Activity Diagram serve a studiare cosa succede
in un sistema. Si tratta sostanzialmente di un
diagramma di flusso. Rappresenta quindi il flusso
di decisioni ed attività che schematizzano il nostro
sistema. E' molto simile a quello che viene
chiamato diagramma di flusso ed è molto utile per
capire come si svolge una certa attività, processo o
operazione.
Esempio
COMPONENT DIAGRAMS
• Il Component Diagram mostra le varie componenti
software di un sistema e le dipendenze che esistono fra di
esse.
• A differenza dei precedenti non sono concettuali ma sono
componenti fisiche del sistema che risiedono sul hardware
del sistema considerato.
• Si tratta quindi di moduli fisici di codice.
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
22
Architettura dei Database Territoriali
Esempio
Pr. R. Laurini
DEPLOYMENT DIAGRAMS
• Il Deployment diagram serve a
rappresentare la struttura fisica e le relazioni
tra hardware e software del nostro sistema.
• Il componente generale di un Deployment
Diagram è detto Nodo e rappresenta una
generica risorsa generalmente hardware.
• Ad esempio può essere un semplice sensore
oppure un mainframe.
Esempio
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
Altro esempio
23
Architettura dei Database Territoriali
Organizzazione dei diagrammi UML
Pr. R. Laurini
3.8 – Conclusioni
• Importanza della modellazione concettuale
• Modello entità-associazione
• Database relazionali
Cap. 3°: Strumenti per la Modellazione degli Oggetti Spaziali
24