I data Bases tra anni ’60 e ’70



Scaricare 1.46 Mb.
26.01.2018
Dimensione del file1.46 Mb.



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

  • 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



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



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.

  • 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

    • 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

  • 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

  • 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

  • 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

    • 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

  • 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

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



Una delle strade per chiudere la frattura era scegliere un modello utilizzabile sia in analisi e progettazione che in programmazione.

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



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.

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





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





Un oggetto è un'entità dotata di:

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





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)



Le proprietà rappresentano i dati dell'oggetto, ovvero le informazioni su cui i metodi possono operare.

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


Un metodo rappresenta una azione che può essere compiuta da un oggetto.

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



Un linguaggio di programmazione per poter essere definito a oggetti deve permettere di realizzare i tre meccanismi seguenti:

  • Un linguaggio di programmazione per poter essere definito a oggetti deve permettere di realizzare i tre meccanismi seguenti:

  • Incapsulamento

  • Ereditarietà

  • Polimorfismo



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.

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



L’ereditarietà permette di derivare nuove classi a partire da classi già definite.

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



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.

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





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





UML supporta l’intero ciclo di sviluppo



Come usare UML













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


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)



Classi



Metodi

  • Il comportamento di una classe è rappresentata dai suoi metodi

  • I metodi possono essere rinvenuti esaminando i diagrammi di interazione



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



Classi



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

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



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à



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



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



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



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





Condividi con i tuoi amici:


©astratto.info 2019
invia messaggio

    Pagina principale