dalle relazioni agli oggetti n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
DALLE RELAZIONI AGLI OGGETTI PowerPoint Presentation
Download Presentation
DALLE RELAZIONI AGLI OGGETTI

Loading in 2 Seconds...

play fullscreen
1 / 75

DALLE RELAZIONI AGLI OGGETTI - PowerPoint PPT Presentation


  • 103 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'DALLE RELAZIONI AGLI OGGETTI' - tanner


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
dalle relazioni agli oggetti

DALLE RELAZIONI AGLI OGGETTI

Opera Collettiva. Gli Autori sono menzionati in coda

i data bases tra anni 60 e 70
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
Nel 1953 appaiono le unità a nastro ei 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
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
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
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

assunzioni di base
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
Il Linguaggio: SQL

Data Manipulation Language

Data Definition Language

1976 il modello entit relazione
1976: Il Modello Entità-Relazione

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
Notazione di Chen

Entità

Studenti

Relazione

Nome

Fax

Proprietà

l importanza dei modelli dei dati
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
Il programmatore di solito usa il Ciclo di Sviluppo Waterfall

Analisi

Progettazione

Programmazione

Test (Ricerca e correzione degli errori)

Documentazione

Installazione

Manutenzione

slide14
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.

La frattura concettuale

i limiti del modello relazionale
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
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
Limiti delle assunzioni di base - 2

I duplicati non sono permessi

Se dovesse capitare, meglio inventarsi un campo chiave artificiale

L’ordine non è importante

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
I Limiti delle assunzioni implicite diffuse

Non e' possibile porre nella base di dati le informazioni sulle informazioni

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.

L'uso dei nomi dei campi e dei nomi dei domini e' privo di significato

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
I Limiti nella realizzazione di una entità - 1

L’identificazione di una entità mediante chiavi primarie ha una utilità limitata

Una chiave “parlante” è utile ma produce dipendenze funzionali, una artificiale non produce dipendenze funzionali ma non è “parlante”

Le informazioni su una entità possono essere su più tabelle

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
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
I Limiti nella realizzazione di una relazione

Il concetto di relazione ha una molteplicità di realizzazioni

Di solito ha tre tipi di realizzazione, a seconda che sia uno a uno, uno a molti o molti a molti

Nel modello relazionale relazioni tra entità non sono descritte

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
I Limiti nel concetto di forme normali

Il modello relazionale non “ricorda” le forme normali

Esse sono solo nella mente del progettista

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

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
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.

slide24
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.

Modelli ad agli Oggetti

da simula a smalltalk
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
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.

slide27
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).

1970-1980 Lo XEROX PARC

adele goldberg la madre della programmazione ad oggetti
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.

slide29

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
Caratteristiche dei Modelli ad Oggetti

Possiamo sintetizzare il paradigma ad oggetti con le seguenti affermazioni:

Ogni cosa è un oggetto

Gli oggetti hanno delle proprietà

Tutti gli oggetti con le stesse proprietà fanno parte della stessa categoria(classe)

Gli oggetti sanno eseguire delle ricette(metodi)

Possono capitare degli eventi che scatenano le ricette

Le proprietà possono essere elementari o essere a loro volta delle classi(aggregazione)

Una classe può aggiungere proprietà e metodi a una classe più astratta(ereditarietà)

slide31

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
Oggetti

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.

slide33

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
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
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
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
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
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
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
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
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
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
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
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.

slide45

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
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

slide48

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
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
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
slide51

Segretario

Professore

Studente

Contabile

Attore

  • Un attore è qualcuno o qualcosa che deve interagire con il sistema da sviluppare
slide52

Gestisce Curriculum

Richiede Libretto Esami

Gestisce Calendario

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
slide53

Richiede Libretto Esami

Professore

Studente

Gestisce Calendario

Contabile

Gestisce Curriculum

Segretario

Diagrammi Use Case

  • I diagrammi Use Case sono creati per visualizzare le relazioni tra attori e use cases
slide54

registrazione

registration

matematica

matematica

Studente

form

manager

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 Sequenza

  • Un diagramma di sequenza mostra le interazioni tra oggetti ordinati in sequenza temporale
slide55

corso form :

1: definisci info corso

CorsoForm

2: processa

3: aggiungi corso

: Segretario

ilManager :

unCorso :

CurriculumManager

Corso

4: nuovo corso

Diagramma di Collaborazione

  • Un diagramma di collaborazione mostra le interazioni tra oggetti
diagrammi di classe
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

classi1
Classi

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)

Studente

Professore

classi2
Classi

ScheduleAlgorithm

RegistrationForm

RegistrationManager

Corso

Studente

Professore

OffertaCorsi

metodi1
Metodi

Il comportamento di una classe è rappresentata dai suoi metodi

I metodi possono essere rinvenuti esaminando i diagrammi di interazione

registration

registration

form

manager

RegistrationManager

3: aggiungi corso(io, matematica)

aggiungiCorso(Studente,Corso)

propriet1
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

OffertaCorsi

numero

sede

orario

Ogni corso offerto

ha un numero, una sede

e un orario

classi3
Classi

ScheduleAlgorithm

RegistrationForm

RegistrationManager

aggiungiStudent(Corso, Studnfo)

Corso

nome

numCrediti

Studente

open()

nome

addStudent(StudentInfo)

diploma

Professore

OffertaCorsi

nome

stato

sede

open()

addStudent(StudentInfo)

relazioni
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à

relazioni1
Relazioni

Una associazione è una connessione bi-direzionale tra classi

Una associazione è tracciata come una linea che collega le classi coinvolte

Una aggregazione è una forma di relazione più forte tra un assieme e le sue parti

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
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 navigabilit1
Molteplicità e Navigabilità

ScheduleAlgorithm

RegistrationForm

0..*

RegistrationManager

1

addStudent(Course, StudentInfo)

Corso

1

name

0..*

numberCredits

Studente

open()

addStudent(StudentInfo)

diploma

1

3..10

1..*

Professore

4

OffertaCorsi

stato

sede

1

0..4

open()

addStudent(StudentInfo)

ereditariet1
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

ereditariet2
Ereditarietà

ScheduleAlgorithm

RegistrationForm

RegistrationManager

addStudent(Course, StudentInfo)

Course

name

RegistrationUser

numberCredits

name

Studente

open()

addStudent(StudentInfo)

diploma

Professore

CorsiOfferti

stato

sede

open()

addStudent(StudentInfo)

the state of diagrammi di transizione
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
State Diagrammi di Transizione

Aggiungi Studente[ conto < 10 ]

Aggiungi Studente /

Set conto = 0

Inizializzazione

Apri

do: Inizializza corso

Cancella

Cancella

[ conto = 10 ]

Cancellato

do: Notifica studenti registrati

Chiuso

Cancella

do: Finalizza corso

entry: Registra studente

exit: Incrementa conto

the la descrizione del mondo fisico
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
La descrizione del mondo fisico

Register.exe

Billing.exe

Contabilita

System

People.dll

Utente

Corso.dll

Corso

Professore

Studente

Corso

Offerta

Corsi

l installazione del sistema
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
Diagramma di Installazione

Segreterie

Database

Edificio

Biblioteca

Principale

Dormitorio

le estensioni
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
Gli Autori

Palmieri

Paradiso

Piroscia

Priano

Prodon L.

Prodon V.

Quaquarelli

Rinaldi

Sgarra

Varola

Zinfollino

Capurso editor

http://info.bazarinfo.info

Amelio

Berardi

Ciani

Concilio

D’Errico

Ferri

Figliolia

Guadagno

Lampo

Lanotte

Matera

Monticelli