DALLE RELAZIONI
AGLI OGGETTI
Opera Collettiva. Gli Autori
sono menzionati in coda
I Data Bases tra anni ’60 e ’70
Negli anni ‘50 i sistemi informativi su computer
memorizzavano le informazioni su scheda
perforata
 Tra il 1961 ed il 1971 i Data Bases decollano

Nel 1953 appaiono le unità a nastro e i
primi Sistemi Informativi






Riutilizzabile
Occupa poco spazio
E’ semplice da trasportare
Contiene una gran quantità di dati
Purtroppo, è sequenziale
Purtroppo, le operazioni richiedono
due unità a nastro
Nel 1959 le unità a disco






Ad accesso diretto
Possibile il collegamento
tra più archivi contemporaneamente
Riutilizzabile
Occupa poco spazio
E’ semplice da trasportare
Contiene una gran quantità di dati
1968: IMS, il primo DBMS IBM
IBM progetta IMS come DBMS per il progetto
APOLLO nel 1966
 Con Rockwell e Caterpillar, IBM lo utilizza per la
prima volta nel 1969 per la gestione degli
approvvigionamenti per la NASA
 Dopo 40 anni, è ancora in commercio
 Il suo creatore Vern Watts lavora ancora nel 2009
(anche se non ufficialmente) per IBM su IMS

Vengono messi a punto gli algoritmi
fondamentali
Accesso Sequenziale
 Accesso Diretto Relativo
 Accesso Sequenziale con Indice
 Tecniche di Ricerca
 Ricerca Binaria
 Indice con B-Tree
 Tecniche Hash

1971: Codd (IBM) mette a punto il
modello relazionale
Assunzioni di Base
I duplicati non sono permessi
 L’ordine non è importante
 I valori sono atomici
 Le colonne sono omogenee
 Le righe sono omogenee

Il Linguaggio: SQL

Data Manipulation Language

Data Definition Language
1976: Il Modello Entità-Relazione


1.
2.
3.
4.
5.
Già nel 1976 Peter Chen evidenzia le difficoltà
del modello relazionale nel rappresentare la
realtà e introduce il modello Entità-Relazione
Più ricco, viene usato per descrivere il modello
delle informazioni come appaiono nella realtà
Ogni cosa è una Entità
Ogni Entità ha delle proprietà
Le Entità con le stesse proprietà fanno parte
dello stesso Insieme di Entità
Tra Entità ci possono essere delle Relazioni
Le Relazioni possono essere 1:1, 1:n, n:n
Notazione di Chen
Entità
Studenti
Relazione
Nome
Fax
Proprietà
L’importanza dei modelli dei dati




Rappresentano la struttura delle informazioni
Il modello concettuale dei dati rappresenta la
struttura delle informazioni inerente al
problema nel mondo reale
Il modello logico dei dati rappresenta la
struttura delle informazioni così come sono
visibili all’utente di un DBMS
Il modello fisico dei dati rappresenta la struttura
delle informazioni così come risiede su memoria
di massa
Il programmatore di solito usa il
Ciclo di Sviluppo Waterfall
Analisi
 Progettazione
 Programmazione
 Test (Ricerca e correzione degli errori)
 Documentazione
 Installazione
 Manutenzione

La frattura concettuale
Nel Ciclo di Sviluppo Waterfall l’informatico analizza e
progetta le informazioni usando un modello
concettuale, di solito ricco e potente. Poi lo converte nel
modello logico secondo quanto permesso dal DBMS
scelto per la programmazione.
 Questo produce una frattura concettuale tra le fasi di
Analisi e Progettazione e quella di Programmazione.
 La frattura crea rumore, che si converte poi in errori.

I Limiti del Modello Relazionale
Ma perché il modello relazionale non è adatto a
fare Analisi e Progettazione ? Quali sono i suoi
limiti ?
 I limiti del modello relazionale sono
raggruppabili in alcune categorie:

I Limiti delle assunzioni di base
 I Limiti delle assunzioni implicite diffuse
 I Limiti nella realizzazione di una entità
 I Limiti nella realizzazione di una relazione
 I Limiti nel concetto di forme normali

Limiti delle assunzioni di base - 1
Le assunzioni di base medesime costituiscono
anche i limiti di ciò che si può rappresentare col
modello relazionale
 Le colonne sono omogenee



Non è possibile avere righe con colonne non
omogenee, ad esempio con sottocategorie
Le righe sono omogenee

Non è possibile avere righe con colonne in numero
superiore o inferiore, ad esempio con sottocategorie
Limiti delle assunzioni di base - 2

I duplicati non sono permessi


L’ordine non è importante


Se dovesse capitare, meglio inventarsi un campo
chiave artificiale
Se dovesse essere importante, l’ordinamento
andrebbe fatto in fase di visualizzazione
I valori sono atomici

Non è possibile rappresentare campi ripetitivi, o
campi con una ulteriore struttura interna
I Limiti delle assunzioni implicite
diffuse

Non e' possibile porre nella base di dati le
informazioni sulle informazioni


L'uso dei nomi dei campi e dei nomi dei domini e'
privo di significato


Il modello relazionale non prevede la presenza di
meta-informazioni in un data dictionary. I DBMS lo
prevedono, ma non è uno standard e ognuno usa
convenzioni proprietarie.
Per il modello relazionale i campi non hanno
significato, se non nella mente del programmatore
Non è possibile cambiare il modello dei dati
dinamicamente durante l’esecuzione

Di solito lo fa il data base administrator
I Limiti nella realizzazione di una
entità - 1

L’identificazione di una entità mediante chiavi
primarie ha una utilità limitata


Le informazioni su una entità possono essere su più
tabelle


Una chiave “parlante” è utile ma produce dipendenze
funzionali, una artificiale non produce dipendenze
funzionali ma non è “parlante”
Di solito, è il risultato di un processo di
normalizzazione
Una tabella può contenere informazioni su molte
entità

Capita se le entità hanno una relazione uno a uno
I Limiti nella realizzazione di una
entità - 2

Una entità può non essere associata ad una
tabella


Può capitare come risultato di un processo di
normalizzazione che un’entità venga polverizzata in
tante tabelle e recuperi esistenza solo con una join
Una tabella puo' non rappresentare alcuna
entità

Capita per una tabella che rappresenta una relazione
molti a molti
I Limiti nella realizzazione di una
relazione

Il concetto di relazione ha una molteplicità di
realizzazioni


Nel modello relazionale relazioni tra entità non
sono descritte


Di solito ha tre tipi di realizzazione, a seconda che sia
uno a uno, uno a molti o molti a molti
Semplicemente il modello relazionale non le prevede
e non può rappresentarle. La presenza di una foreign
key fa solo ipotizzare la presenza di una relazione
La distinzione tra proprietà e relazione è tenue

Accade se una entità ha una sola proprietà o se due
entità hanno una relazione uno a uno
I Limiti nel concetto di forme
normali

Il modello relazionale non “ricorda” le forme
normali


La normalizzazione peggiora le prestazioni e
costringe a ricalcolare i risultati in continuazione


Se decompongo una entità in più tabelle per portarle
in 3NF, poi la devo ricostruire a colpi di join
La denormalizzazione migliora le prestazioni ma
produce ridondanza e rischio di incongruenza


Esse sono solo nella mente del progettista
Non decompongo una entità che è in 2NF
Le assunzioni dietro le forme normali possono
venir meno durante la vita di un modello
Dalle Informazioni agli Oggetti
Sarebbe bello dunque avere una unica
rappresentazione per il modello concettuale e
logico
 Nel 1971 Codd introduce il modello relazionale
delle informazioni, raggruppate in tabelle con
righe e colonne
 Nel 1976-1978 Peter Chen suggerisce l’uso di
concetti più ricchi di significato, Entità con
Proprietà e Relazioni, per rappresentare le
informazioni del modello concettuale e logico
 Nel 1978 Michael Hammer and Dennis McLeod
suggeriscono l’uso di modelli semantici (ad
oggetti). Siamo ormai agli oggetti.

Modelli ad agli Oggetti



Una delle strade per chiudere la frattura era scegliere
un modello utilizzabile sia in analisi e progettazione
che in programmazione.
I primi linguaggi ad usare un modello di tal genere
furono il SIMULA I e il SIMULA 67
Creati da Ole-Johan Dahl e Kristen Nygaard in
Norvegia tra il 1962 ed il 1967 , usavano i concetti di
oggetti e classi, ma non ottennero molto successo.
Da SIMULA a SMALLTALK


Allo XEROX PARC Alan Kay, ricercatore
dell'università dello Utah, influenzato da
SIMULA, inventa SMALLTALK, considerato da
molti il primo vero linguaggio con un modello ad
oggetti "puro".
SMALLTALK successivamente viene ripreso da
un team di ricercatori tra cui Adele Goldberg e
Daniel Ingalls ed utilizzato nello XEROX ALTO,
quello che è considerato il padre dei moderni
Personal Computers.
I contributi della XEROX



Fondata a Rochester, New York, negli Stati Uniti nel
1906 col nome di Haloid come produttrice di carta per
fotografia, nel 1961 l'azienda mutò il nome in Xerox
Corporation dopo che nel 1944 investì nella xerografia,
tecnica di fotocopiatura inventata dal fisico americano
Chester Carlson nel 1938, brevettata il 6 ottobre 1942
con il numero 2297691.
La tecnica fu chiama Xerografia, dalla parola greca
Xeròs che significa secco, per distinguerla dai processi
precedenti che impiegavano reazioni chimiche in
soluzioni acquose. La tecnica fece guadagnare una
fortuna.
Con i soldi guadagnati, la XEROX investe
nell’innovazione e fonda lo XEROX PARC.
1970-1980 Lo XEROX PARC
Nel 1970 la Xerox fonda lo Xerox Palo Alto
Research Center(PARC). PARC è la più famosa
divisione di ricerca della Xerox Corporation,
localizzata a Palo Alto, California, USA. E’ stata
separata dalla casa madre nel 2002.
 Xerox PARC è stato l'incubatore di molti
componenti dei moderni computer,inclusi molti
aspetti delle interfacce grafiche (GUI), il mouse,
gli editor di testo WYSIWYG, le stampanti laser,
i computer da tavolo, il linguaggio Smalltalk, gli
ambienti di sviluppo integrati, Ethernet e i
linguaggi di descrizione di pagina (precursori del
PostScript).

Adele Goldberg, la madre della
programmazione ad oggetti



Adele Goldberg, nata il 22 Luglio 1945,
ricercatrice allo XEROX PARC, avendo
coordinato lo sviluppo del linguaggio di
programmazione Smalltalk-80, partecipato allo
sviluppo dello XEROX ALTO e scritto libri
sull’argomento, è considerata la madre della
programmazione ad oggetti.
Apple usò molte delle idee e delle soluzioni
usate nell’Alto come base per il Macintosh.
Fondatrice di ParcPlace-Digitalk, ex Presidente
dell’ACM, Adele Goldberg lavora attualmente
in Neometron, Inc. a Palo Alto, California.
Da SMALLTALK a JAVA
Da Smalltalk negli anni ‘80 sono state create
estensioni orientate ad oggetti del linguaggio C
(C++, Objective C, e altri), e di altri linguaggi
(Object Pascal).
 Negli anni ‘90 è gradualmente diventato il
paradigma dominante.
 Oggi, i linguaggi più usati sono quelli che
supportano anche il paradigma di
programmazione orientata agli oggetti, come
C++, Java, Delphi, Python, C#, Visual Basic
.NET, Perl, PHP (a partire dalla versione 5).

Caratteristiche dei Modelli ad
Oggetti
Possiamo sintetizzare il paradigma ad oggetti con
le seguenti affermazioni:
1. Ogni cosa è un oggetto
2. Gli oggetti hanno delle proprietà
3. Tutti gli oggetti con le stesse proprietà fanno
parte della stessa categoria(classe)
4. Gli oggetti sanno eseguire delle ricette(metodi)
5. Possono capitare degli eventi che scatenano le
ricette
6. Le proprietà possono essere elementari o essere
a loro volta delle classi(aggregazione)
7. Una classe può aggiungere proprietà e metodi a
una classe più astratta(ereditarietà)
L’oggetto come concetto primitivo
Quello di oggetto è un concetto primitivo, che non si
può spiegare mediante altri termini. Un oggetto è una
qualsiasi cosa che ci circonda. Ma in informatica
assume un significato diverso.
Oggetti

1.
2.
3.
Un oggetto è un'entità dotata di:
Identità: che permette quindi sempre di
distinguere un oggetto da un altro (un "numero di
serie")
Stato: quindi in grado di "ricordare" qualcosa.
Comportamento: che si traduce nella possibilità
di osservare (in tutto o in parte) lo stato e
di modificare lo stato, tramite l'invocazione dei
metodi sull'oggetto.
Costruzione e Distruzione di un Oggetto
Un oggetto si costruisce
istanziando il suo stampo,
così come viene usato un
determinato stampo per
fare dei biscotti dalle
forme diverse
Così come un oggetto viene
creato, è possibile anche
distruggerlo; si tratta della
cancellazione, della
sparizione completa
dell’oggetto
Classi



Una classe è un raggruppamento di oggetti con
stesse proprietà e stessi metodi, dunque un
insieme di oggetti dello stesso tipo.
Un’istanza è un particolare oggetto di una
determinata classe. Ogni istanza è separata
dalle altre, ma condivide le sue caratteristiche
generali con gli altri oggetti della stessa classe.
La maggior parte dei linguaggi richiama cosi le
proprietà di un oggetto:
oggetto.attributo
oggetto.metodo(parametri)
Proprietà
Le proprietà rappresentano i dati dell'oggetto, ovvero
le informazioni su cui i metodi possono operare.
 Un oggetto per essere ben definito deve contenere le
proprietà che servono e non tutte quelle che gli si
potrebbero comunque attribuire.
 In generale, esistono tre tipologie di proprietà:

Gli attributi rappresentano quelle proprietà che
descrivono le caratteristiche peculiari di un oggetto (ad
esempio, per una persona: altezza e peso).
 I componenti, proprietà che a loro volta sono oggetti e che
ne costituiscono parte.(PART-OF)
 GIi oggetti associati, proprietà che a loro volta sono altri
oggetti collegati, ma non parte (ad esempio: l'automobile
posseduta da una persona).

Metodi


Un metodo rappresenta una azione che può
essere compiuta da un oggetto.
Una delle domande principali da porsi quando si
vuole creare un oggetto è:
Cosa si vuole che sia in grado di fare?

Da osservare:
Un oggetto che abbia uno o due soli metodi deve
fare riflettere.
• Da evitare sono gli oggetti con nessun metodo
• Da evitare sono anche gli oggetti con troppi
metodi.
•
Comunicare con gli oggetti: i messaggi
Come comunicano gli oggetti tra loro ? Come comunica
l’ambiente esterno con gli oggetti ?
I diversi metodi vengono scatenati da sollecitazioni tra
oggetti chiamate eventi o messaggi, che costituiscono il
cuore della comunicazione nel modello ad oggetti.
Caratteristiche di un linguaggio ad
oggetti
Un linguaggio di programmazione per poter
essere definito a oggetti deve permettere di
realizzare i tre meccanismi seguenti:
Incapsulamento
 Ereditarietà
 Polimorfismo

Incapsulamento
L'incapsulamento è la proprietà per cui un oggetto
contiene ("incapsula") al suo interno gli attributi
(dati) e i metodi (procedure) che accedono ai dati
stessi.
 Lo scopo principale dell'incapsulamento è appunto
dare accesso ai dati incapsulati solo attraverso i
metodi definiti, nell'interfaccia, come accessibili
dall'esterno.
 Gestito in maniera intelligente, l'incapsulamento
permette di vedere l'oggetto come una black-box,
cioè una scatola nera di cui, attraverso
l‘interfaccia, sappiamo cosa fa e come interagisce
con l'esterno ma non come lo fa. I vantaggi
principali portati dall'incapsulamento sono:
robustezza, indipendenza e l'estrema
riusabilità degli oggetti creati.

Occultamento o Information Hiding



L’Occultamento per la Programmazione ad
Oggetti è equivalente all’ Information Hiding
della Programmazione Strutturata. L’oggetto è
il nuovo Modulo.
L'utente di un servizio (metodo) di un oggetto è
tenuto a conoscere solo le informazioni
strettamente necessarie per usufruire del
servizio. Ogni altra informazione può
confondere l'utente e/o mettere a rischio
l'integrità dell'oggetto stesso.
L'utente deve conoscere solo l' interfaccia della
classe, cioè il suo nome, le proprietà pubbliche
ed i suoi metodi.
Ereditarietà
L’ereditarietà permette di derivare nuove classi a
partire da classi già definite.
 L'ereditarietà permette di aggiungere proprietà
ad una classe e di modificare il comportamento
dei metodi, in modo da adattarli alla nuova
struttura della classe.
 Da una stessa classe è possibile costruire diverse
classi derivate. Da una classe derivata è possibile
derivarne un'altra con lo stesso meccanismo.
 L'ereditarietà può essere usata anche come
meccanismo per gestire l'evoluzione ed il riuso del
software.

Ereditarietà e Sottoclassi


L'ereditarietà (inheritance) è il meccanismo che
consente ad una classe (sottoclasse) di considerarsi
erede (specializzazione) di un'altra, detta classe padre
o genitore (parent class o superclasse o
generalizzazione)
Così facendo la classe detta classe figlia (o classe
derivata o sottoclasse), eredita tutte le proprietà della
classe padre specificata, cioè tutti gli attributi e i
metodi (anche quelli nascosti).
La Classificazione delle Classi o
Tassonomia
Normalmente i linguaggi ad oggetti classificano
tulle le classi conosciute in un albero di
classificazione o TASSONOMIA.
 Tale Tassonomia di classi con proprietà e metodi
rappresenta una delle grandi ricchezze dei
linguaggi ad oggetti, permettendo il riuso del
codice.

Polimorfismo
La possibilità che le classi derivate
implementino in modo differente i
metodi e le proprietà dei propri
antenati rende possibile che gli oggetti
appartenenti a delle sottoclassi di una
stessa classe rispondano diversamente
alle stesse istruzioni.
 I metodi che vengono ridefiniti in una
sottoclasse sono detti "polimorfi", in
quanto lo stesso metodo si comporta
diversamente a seconda del tipo di
oggetto su cui è invocato.

Il Successo dei Modelli ad Oggetti
La programmazione ad oggetti è
senz’altro il paradigma di
programmazione più utilizzato e
diffuso negli ultimi decenni.
 Questo ha trascinato al successo anche
i Modelli ad Oggetti
 Negli anni ’80-’90 sono state messe a
punto più di 50 variazioni dei modelli
ad oggetti
 A fine anni ’90 il processo di
standardizzazione ha portato ad UML

Uniform Modeling Language

E’ un linguaggio di modellazione e specifica ad
oggetti che unifica i modelli ad oggetti di maggior
successo:
OMT (Object Modeling Technique) di Jim Rumbaugh
 Il metodo Booch di Grady Booch
 OOSE (Object Oriented Software Engineering) di
Ivar Jacobson

Messo a punto dalla Rational Software nel 1995
 Standardizzato dal consorzio OMG (Object
Management Group)
 UML 2.0 (2005) è la versione attuale

La Timeline di UML
Cos’è UML?


UML significa Unified (o Uniform) Modeling Language
UML combina il meglio del meglio del
Data Modeling (Entity Relationship)
 Business Modeling (work flow) (Yourdon-DeMarco)
 Object Modeling
 Component Modeling



UML è la notazione standard per visualizzare,
specificare, construire e documentare i risultati di un
sistema software
Può essere usato con tutti i processi di sviluppo del
software e con differenti tecnologie di implementazione
UML supporta l’intero ciclo di
sviluppo
Business Objects
Relazioni
Oggetti
Sistemi su grande scala
DBMS
Oracle
Classi
Suddivisione delle
applicazioni
Componenti
Microsoft
Scenari
CORBA
OMG
Use Cases
ActiveX/COM
Microsoft
Processi di Business
Come usare UML

UML può essere usato per:






Mostrare il contorno di un sistema e le sue principali
funzionalità attraverso i casi di uso e gli attori
Illustrare le realizzazioni dei casi di uso mediante i
diagrammi di interazione
Rappresentare la struttura statica di un sistema usando i
diagrammi di classe
Modellare il comportamento degli oggetti con i diagrammi
di transizione di stato
Rivelare l’ architettura fisica della soluzione con i
diagrammi dei componenti e della loro localizzazione
Estendere le funzionalità con gli stereotipi
Attore

Un attore è qualcuno o qualcosa che deve interagire
con il sistema da sviluppare
Segretario
Professore
Studente
Contabile
Casi di Uso

Un caso di uso (use case) è una modalità di
comportamento che il sistema mostra


Ogni use case è una sequenza di interazioni correlate
eseguite da un attore e dal sistema in un dialogo
Gli Attori vengono esaminati per determinarne le
necessità




Segretario -- gestisce il curriculum
Professore -- richiede il libretto con gli esami
Studente -- gestisce il proprio calendario degli esami
Contabile -- riceve le informazioni contabili
Gestisce Curriculum
Richiede Libretto Esami
Gestisce Calendario
Diagrammi Use Case

I diagrammi Use Case sono creati per visualizzare le
relazioni tra attori e use cases
Richiede Libretto Esami
Professore
Studente
Gestisce Calendario
Contabile
Gestisce Curriculum
Segretario
Diagramma di Sequenza

Un diagramma di sequenza mostra le interazioni tra
oggetti ordinati in sequenza temporale
registrazione
form
Studente
registration
manager
matematica
matematica
sezione 1
1: riempi info
2: Invia
3: aggiungi corso(io, matematica)
4: sei aperto ?
5: sei aperto ?
6: aggiungi (io)
7: aggiungi (io)
Diagramma di Collaborazione

Un diagramma di collaborazione mostra le interazioni
tra oggetti
1: definisci info corso
2: processa
corso form :
CorsoForm
3: aggiungi corso
: Segretario
ilManager :
CurriculumManager
unCorso :
Corso
4: nuovo corso
Diagrammi di Classe


Un diagramma di classe mostra l’esistenza di
classi e la loro relazione nel sistema
Gli elementi di modellazione che UML fornisce
nei diagrammi di classe sono




Le Classi e la loro struttura e comportamento
Le relazioni di associazione, aggregazione,
dipendenza ed ereditarietà
Indicatori di molteplicità e navigabilità
Nomi di ruolo
Studente
Classi
Studente




Una classe è una collezione di oggetti con
comune struttura, comportamento, relazioni and
significato
Le classi sono individuate esaminando gli oggetti
nei diagrammi di sequenza e collaborazione
Una classe viene disegnata come un rettangolo
con tre compartimenti
Le classi dovrebbero essere chiamate usando il
vocabolario del dominio applicativo, seguendo
uno standard (ad esempio, nomi singolari che
iniziano con una lettera maiuscola)
Professore
Classi
ScheduleAlgorithm
RegistrationForm
RegistrationManager
Corso
Studente
Professore
OffertaCorsi
Metodi


Il comportamento di una classe è rappresentata
dai suoi metodi
I metodi possono essere rinvenuti esaminando i
diagrammi di interazione
registration
form
registration
manager
RegistrationManager
3: aggiungi corso(io, matematica)
aggiungiCorso(Studente,Corso)
Proprietà


La struttura di una classe è rappresentata dalle
sue proprietà
Le proprietà possono essere rinvenute
esaminando le definizioni di classe, i requisiti
del problema, e applicando la conoscenza del
dominio
Ogni corso offerto
ha un numero, una sede
e un orario
OffertaCorsi
numero
sede
orario
Classi
ScheduleAlgorithm
RegistrationForm
RegistrationManager
aggiungiStudent(Corso, Studnfo)
Corso
nome
numCrediti
Studente
open()
addStudent(StudentInfo)
nome
diploma
Professore
nome
stato
OffertaCorsi
sede
open()
addStudent(StudentInfo)
Relazioni



Le Relazioni forniscono un meccanismo di
comunicazione tra oggetti
I diagrammi di sequenza e/o collaborazione
vengono esaminati per determinare quali
collegamenti tra oggetti devono esistere per
realizzare il comportamento previsto. Ad
esempio, se due oggetti devono “parlare” deve
esserci un collegamento
Ci sono quattro tipi di relazioni:
Associazione
 Aggregazione
 Dipendenza
 Ereditarietà

Relazioni

Una associazione è una connessione bidirezionale tra classi


Una aggregazione è una forma di relazione più
forte tra un assieme e le sue parti


Una associazione è tracciata come una linea che
collega le classi coinvolte
Una aggregazione è tracciata come una linea che
collega le classi coinvolte con un diamante vicino
alla classe che rappresenta l’assieme
Una relazione di dipendenza è una forma di
relazione più debole tra un cliente e un fornitore
dove il cliente non ha conoscenza del fornitore

Una relazione di dipendenza è tracciata come una
linea tratteggiata che punta dal cliente al
fornitore
Molteplicità e Navigabilità

La Molteplicità definisce quanti oggetti
partecipano a una relazione
La Molteplicità è il numero di istanze di una
classe legate a UNA istanza dell’altra classe
 Per ciascuna associazione e aggregazione, ci sono
due decisioni di molteplicità da prendere: una per
ciascun lato della relazione.



Sebbene le associazioni e le aggregazioni siano
normalmente bi-direzionali, è spesso
desiderabile restringere la navigabilità a una
direzione
Se la navigabilità viene ristretta, si aggiunge
una punta di freccia per indicare la direzione di
navigazione
Molteplicità e Navigabilità
ScheduleAlgorithm
RegistrationForm
0..*
1 RegistrationManager
addStudent(Course, StudentInfo)
Corso
1
0..*
Studente
name
numberCredits
open()
addStudent(StudentInfo)
diploma
1
3..10
Professore
4
stato
1
1..*
OffertaCorsi
sede
0..4
open()
addStudent(StudentInfo)
Ereditarietà


L’ereditarietà è una relazione tra una
superclasse e le sue sottoclassi
Ci sono due modi per guardare l’ereditarietà :
la Generalizzazione
 la Specializzatione


Le proprietà, i metodi e le relazioni comuni,
vengono mostrate al più alto livello possibile
nella gerarchia
Ereditarietà
ScheduleAlgorithm
RegistrationForm
RegistrationManager
addStudent(Course, StudentInfo)
Course
name
numberCredits
RegistrationUser
name
Studente
open()
addStudent(StudentInfo)
diploma
Professore
stato
CorsiOfferti
sede
open()
addStudent(StudentInfo)
The State of Diagrammi di
Transizione

Un diagramma di transizione di stato mostra
La storia della vita di una data classe
 Gli eventi che causano la transizione da uno stato
ad un altro
 Le azioni che resultano da un cambiamento di
stato


I diagramma di transizione di stato vengono
prodotti per oggetti con un comportamento
dinamico significativo
State Diagrammi di Transizione
Aggiungi Studente[ conto < 10 ]
Inizializzazione
Aggiungi Studente /
Set conto = 0
do: Inizializza corso
Apri
entry: Registra studente
exit: Incrementa conto
Cancella
Cancella
[ conto = 10 ]
Cancellato
do: Notifica studenti registrati
Cancella
Chiuso
do: Finalizza corso
The La descrizione del mondo
fisico


I Diagrammi dei Componenti illustrano la
organizzazione e le dipendenze tra le componenti
software
Una componente può essere



Una componente di codice sorgente
Una componente di libreria
Una componente eseguibile
La descrizione del mondo fisico
Register.exe
Billing.exe
Contabilita
System
People.dll
Utente
Corso.dll
Corso
Studente
Corso
Offerta
Corsi
Professore
L’installazione del Sistema


Il diagramma di installazione mostra la
configurazione degli elementi di processing in
esecuzione e i processi software che risiedono su
di essi
Il diagramma di installazione mostra la
distribuzione dei componenti nella realtà
aziendale.
Diagramma di Installazione
Segreterie
Database
Edificio
Principale
Biblioteca
Dormitorio
Le Estensioni



Gli Stereotipi possono essere usati per estendere
gli elementi della notazione UML
Gli Stereotipi possono essere usati per
classificare e estendere le associazioni, le
relazioni di ereditarietà, le classi, e le
componenti
Ad esempio:
Stereotipi di Classe : confini, controllo, entità,
utilità, eccezioni
 Stereotipi di Ereditarietà : usa ed estende
 Stereotipi di Componenti : sottosistemi

Gli Autori
Amelio
Berardi
Ciani
Concilio
D’Errico
Ferri
Figliolia
Guadagno
Lampo
Lanotte
Matera
Monticelli
Palmieri
Paradiso
Piroscia
Priano
Prodon L.
Prodon V.
Quaquarelli
Rinaldi
Sgarra
Varola
Zinfollino
Capurso editor
http://info.bazarinfo.info