Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Scienze Matematiche Fisiche e Naturali
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Massimo Brescia » 28.Tecnologie di indagine scientifica in Astrofisica - parte quinta


Introduzione

SCOPO DELLA LEZIONE:

Nozionistica basilare sulle metodologie standard di progettazione ed implementazione del software, per fornire un utile senso critico in un “ambiente” sempre più legato all’automazione e agli standard.

Argomenti della lezione:

  1. introduzione al paradigma della programmazione ad oggetti (OOP – Object Oriented Programming);
  2. caratteristiche e meccanismi della programmazione ad oggetti;
  3. introduzione all’ingegneria del software;
  4. processi di sviluppo ed attività strutturali;
  5. Unified Modeling Language, UML;
  6. rappresentazione del progetto: modelli e diagrammi;
  7. middleware;
  8. sistemi informativi e standardizzazione dei dati.

Repetita iuvant

Riprendiamo alcuni concetti vedendo qualche esempio…

Esempio di programma per effettuare la somma di due numeri interi nel linguaggio C++:

int main() {
int op1, op2, somma; //dichiarazione delle var.
cout<<"inserisci un operando intero"<>op1; //salva il numero inserito nella variabile op1
cout<<"inserisci l'altro operando intero"<>op2; //salva il numero inserito nella variabile op2
Somma=op1+op2; //effettua la somma
cout<<"Somma="<<
return 0;}

Esempio di programma per effettuare la somma di due numeri interi nel linguaggio Java:

public static void main(String s[]) {
int op1, op2, somma; //dichiarazione delle var.
op1=Integer.parseInt(s[0]); //parsing del parametro primo operando
op2=Integer.parseInt(s[1]); //parsing del parametro secondo operando
somma=op1+op2; //effettua la somma
System.out.println("Somma="+somma); //stampa a video il risultato dell'operazione
}

OOP – Introduzione

  • La Programmazione Orientata agli Oggetti (OOP) è un paradigma di programmazione, ovvero un insieme di regole e strumenti concettuali che definiscono la percezione del programma da parte dello sviluppatore. L’OOP definisce il concetto di “oggetto” software, dotandolo di dati propri, “attributi”, e “metodi” per poter accedere ad essi. Più in generale possiamo dire che l’OOP prevede l’esistenza di oggetti “virtuali” modulati come oggetti reali.
  • Un programma realizzato secondo il paradigma OOP può considerarsi “ben fatto”, secondo i criteri del paradigma, se è completamente costituito da oggetti che interagiscono tra di loro al fine di raggiungere lo scopo previsto.
  • L’OOP prevede di raggruppare gli oggetti in “classi”. Un oggetto non è altro che un istanza di una classe, cioè un particolare oggetto della classe, separato dagli altri ma che ne condivide le caratteristiche generali.
  • Esempio: la classe delle persone rappresenta l’insieme di tutte le persone: un istanza di questa classe è Mario Rossi nato a Roma il 25/12/00.
Fig. 1: Classi & oggetti (A. Nocella)

Fig. 1: Classi & oggetti (A. Nocella)


OOP – Una classe in Java


OOP – Proprietà

Le proprietà fondamentali della programmazione ad oggetti.

  1. Information hiding: è il principio di base della tecnica dell’incapsulamento. Tale tecnica in generale serve a garantire che una parte di programma possa nascondere le proprie informazioni incapsulandole in un costrutto dotato di interfaccia. Tale tecnica permette di evitare che un’errata implementazione di un modulo del programma si ripercuota sull’intero progetto.
  2. Ereditarietà: proprietà fondamentale dell’OOP, essa permette di definire classi come sottoclassi derivate da altre, istituendo una relazione di generalizzazione tra la classe derivata e quella base (di specializzazione viceversa). La sottoclasse eredita tutte le caratteristiche della classe base. L’ereditarietà può essere semplice o multipla se la classe figlia deriva da più classi padre. Da questa proprietà ha origine il concetto di polimorfismo e le tecniche di overriding e classi astratte.
  3. Polimorfismo: concetto ampio che si potrebbe riassumere nel fatto che un espressione, il cui tipo è descritto in una data classe, può assumere valori di un qualunque tipo descritto da una sottoclasse di quella d’origine (binding dinamico).

OOP – Relazioni

Relazioni tra classi.

  1. Generalizzazione/Specializzazione: è la relazione che sussiste tra un oggetto padre ed un oggetto figlio.
  2. Associazione: è la relazione più “semplice” che può sussistere tra due oggetti di classi diverse e che non ne determina alcuna forma di inclusione o generalizzazione/specializzazione.
  3. Aggregazione larga: spesso semplicemente detta aggregazione è la relazione che sussiste tra oggetti di classi diverse, in particolare tra gli oggetti aggreganti e l’oggetto aggregato. Gli oggetti in questione hanno cicli di vita indipendenti. (un buon esempio è quello di un automobile aggregato di motore, ruote e carrozzeria).
  4. Aggregazione stretta: o anche composizione, è la relazione che sussiste tra gli oggetti componenti ed uno composto, come per l’aggregazione, con la differenza che in questo caso tutti gli oggetti hanno cicli di vita correlati.

OOP – Riepilogo

Ricapitolando…

  • Una classe è un’entità logica;
  • Una classe è un tipo di dato complesso;
  • Una classe è un contenitore di oggetti;
  • Una classe descrive le proprietà strutturali e comportamentali dei suoi oggetti;
  • Una classe è un metadato (un’informazione che descrive un insieme di dati);
  • Un oggetto è un entità “concreta“;
  • Un oggetto è un dato complesso;
  • Un oggetto è un istanza di una classe e quindi appartiene sempre ad una classe;
  • Le proprietà strutturali e comportamentali di un oggetto sono quelle descritte dalla classe cui esso appartiene;
  • I dati e i dettagli implementativi sono incapsulati;
  • L’accesso ai dati avviene attraverso i metodi definiti (essi rappresentato un’interfaccia);
  • Tutti gli attributi di una classe dovrebbero essere privati;
  • Il polimorfismo rappresenta la possibilità di un’entità di assumere più forme;
  • Un programma ad oggetti realizza il suo scopo attraverso le relazioni e le interazioni tra oggetti.

Software Engineering – Definizione

Per ingegneria del software si intende la branca dell’ingegneria che si occupa dei processi produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi software. Rispetto al termine “informatica”, che può essere usato per riferirsi alla scienza del calcolo automatico (computer science in inglese), l’ingegneria del software ha come proprio oggetto di studio l’uso e lo sviluppo delle metodologie e tecnologie informatiche di supporto al processo di sviluppo del software.[...]
L’ingegneria del software identifica una formalizzazione del processo di realizzazione di un prodotto software per computer dalla fase di concepimento fino alla sua morte funzionale.[...]
La necessità di creare una scienza che si occupi della realizzazione dei software nasce dalla necessità di sviluppare prodotti sempre più complessi ed evoluti che rispondano a esigenze sempre più specifiche
.

da Wikipedia

S. E. – Processo di sviluppo

  • Un processo di sviluppo è una “struttura” di riferimento entro la quale si svolgono le attività finalizzate alla realizzazione del prodotto di interesse, nel nostro caso un prodotto software, rispettando dei parametri di qualità prefissati.
  • Il processo di sviluppo definisce regole standard e metodologie al fine di raggiungere lo scopo previsto nel rispetto dei parametri qualitativi.
  • Il processo determina anche le scadenze temporali delle attività e le responsabilità delle medesime.
  • Il processo determina quante e quali devono essere le attività e quali azioni compiere per raggiungere i singoli task.
Fig. 2: Processo di sviluppo (A. Nocella)

Fig. 2: Processo di sviluppo (A. Nocella)


S. E. – Processo di sviluppo

  • Un processo di sviluppo non può prescindere da metodologie, tecniche e regole standard;
  • Le attività strutturali del processo hanno un ordinamento preciso che definisce un modello di sviluppo;
  • L’output di ogni attività strutturale, fase del processo, è l’input della fase successiva;
  • Le attività strutturali di un dato modello di processo sono necessarie alla conclusione del processo: non è possibile prescindere da nessuna di esse;
  • Le fasi di sviluppo sono iterative;
  • Un processo di sviluppo può essere iterativo;

Le caratteristiche fin qui analizzate fanno riferimento ai modelli di processo tradizionali nell’ambito dell’ingegneria del software. Esistono anche modelli moderni di maggiore flessibilità, detti modelli agili, le cui caratteristiche non rispettano necessariamente tutti o alcuni dei punti su menzionati.

S. E. – Attività o fasi

Attività strutturali tipiche dei modelli di processo dell’ingegneria del software:

  1. Comunicazione e raccolta dei requisiti di progetto: in questa fase le azioni concorrono all’obiettivo di raccogliere tutti i requisiti necessari alla definizione del prodotto da sviluppare. La comunicazione con il “committente” del prodotto è al centro dell’attività. Output di questa fase è un documento di descrizione del prodotto da sviluppare.
  2. Pianificazione: in questa fase il team di lavoro valuta i requisiti raccolti e ne studia le possibili soluzioni al fine di stabilire le risorse lavoro e tempo necessarie al concludere un ciclo progettuale. Output di questa fase, insieme al documento prodotto in precedenza, è una schedula di progetto con assegnazione di responsabilità, forza lavoro e scadenze delle fasi successive.
  3. Modellazione: in questa fase si realizza la progettazione del prodotto. Questa attività si compone di almeno due azioni.

S. E. – Attività o fasi

  • Analisi dei requisiti: si estrapolano dal documento di input dell’attività i requisiti espliciti ed impliciti del prodotto. Questa è una fase di studio il cui output è un documento di Specifica dei Requisiti. E’ bene che tale documento rispetti uno standard universalmente riconosciuto per eventuali collaborazioni, sviluppi futuri o pubblicazioni. In definitiva l’output della fase sarà un S.R.S. ISO compliant (Standard Requirements Specification).
  • Design: si progetta il prodotto nelle sue caratteristiche statiche e dinamiche e se ne “disegnano” i componenti attraverso un formalismo standard che ne permetta la riusabilità e la diffusione. Tale formalismo rappresenta un metalinguaggio di modellazione e deve, per essere completo, prevedere l’uso di diagrammi che siano in grado di rappresentare qualsiasi informazione di progetto, sia statica che dinamica.

Output della fase di modellazione saranno l’SRS e i diagrammi di design.

S. E. – Attività o fasi

Dopo la modellazione le attività strutturali si diramano in due direzioni parallele:

  • 4. A) Implementazione: in questa fase si “costruisce” il prodotto. Questa attività si realizza in due azioni fondamentali.
  • Scrittura del codice: scrittura nel linguaggio di programmazione scelto, secondo il paradigma OOP, dei componenti del progetto.
  • Debug del codice: verifica e risoluzione di bug (errori del codice) dei sorgenti del prodotto.

Output della fase di implementazione saranno i sorgenti debuggati del prodotto e la relativa documentazione.

S. E. – Attività o fasi

  • 4. B) Programmazione del Testing: in questa fase, parallela all’implementazione, si progetta la politica di Testing dell’implementazione per verificare che questa rispetti le specifiche date nel SRS. Questa attività è composta da almeno due azioni:
  • Progettazione del Testing: si definisce la tecnica di realizzazione dei Test. In alcuni casi (Testing Automation) questa azione coincide con lo sviluppo di un vero e proprio prodotto software per l’automazione del Testing.
  • Stesura dei Test Case: si scrivono i casi di Test a cui sottoporre l’implementazione del prodotto per verificare la corrispondenza alle specifiche.

Output della fase di programmazione del Testing saranno i test case ed eventualmente il software di Testing Automation.

A questo punto lo sviluppo converge nuovamente in un’unica attività strutturale.

S. E. – Attività o fasi

Fasi conclusive del processo di sviluppo:

  • 5. Testing e rilascio del progetto: in questa fase l’implementazione del progetto viene sottoposta ai casi di test secondo la politica convenuta, eventualmente attraverso il software di test appositamente realizzato, per verificare la corrispondenza con le specifiche. Output di questa fase è il rilascio del prodotto nella versione corrente e tutta la documentazione pubblica relativa.
  • 6. Deployment: in questa fase si realizza il deployment dei componenti del prodotto negli appositi ambienti. Nel caso più semplice tale operazione coincide con una installazione del prodotto nel sistema di deposito.

Con il Deployment finisce un ciclo del processo!

Per ottenere il risultato migliore possibile è estremamente probabile che tali attività debbano essere ripetute iterando l’intero processo.

Per questo esiste uno standard anche per indicare le versioni del software e le loro build.

S. E. – Unified Modeling Language

Facciamo un salto indietro alla fase di modellazione. Di questa abbiamo detto…

Modellazione: in questa fase si realizza la progettazione del prodotto. Questa attività si realizza in almeno due azioni.

  • Analisi dei requisiti.
  • Design: si progetta il prodotto nelle sue caratteristiche statiche e dinamiche e se ne “disegnano” i componenti attraverso un formalismo standard che ne permetta la riusabilità e la diffusione. Tale formalismo rappresenta un metalinguaggio di modellazione e deve, per essere completo, prevedere l’uso di diagrammi che siano in grado di rappresentare qualsiasi informazione di progetto, sia statica che dinamica.

Si evidenzia la necessità di adottare un metalinguaggio che sia un formalismo standard per la progettazione di software. Tale formalismo deve permettere di modellare un progetto software in maniera efficiente e funzionale, e contemporaneamente favorire la collaborazione e la divulgazione attraverso una facile comprensione delle caratteristiche del progetto. Quindi è evidente che un formalismo del genere deve essere uno standard: un linguaggio di modellazione unico…

U.M.L.
Unified Modeling Language

S. E. – Unified Modeling Language

Che cos’è UML?!

  • È un linguaggio di progettazione e non un linguaggio di programmazione. È utile a progettare (o ad apportare modifiche) senza scendere nei dettagli dei linguaggio di programmazione.
  • Non è un processo di sviluppo, bensì un possibile strumento.
  • È una notazione standard basata sull’OOP.
  • È indipendente dal particolare processo di sviluppo.
  • È dotato di una grammatica propria. È basato su un meta-modello integrato, composto da numerosi elementi collegati tra loro secondo regole grammaticali precise.
  • Gli elementi progettuali hanno una rappresentazione grafica specifica.
  • Gli elementi del meta-modello possono comparire in diagrammi di diverso tipo.
Fig. 3: UML official logo

Fig. 3: UML official logo


S. E. – UML Diagrams – 1

Fig. 4: UML Diagrams (A. Nocella)

Fig. 4: UML Diagrams (A. Nocella)


S. E. – UML Diagrams – 2

  • Use Case Diagram: rappresenta le funzionalità del sistema da un punto di vista esterno ad esso.
  • Class Diagram: rappresenta le classi che compongono il sistema e le relazioni tre esse.
  • Object Diagram: rappresenta gli oggetti del sistema e le relazioni tra essi.
  • Sequence Diagram: rappresenta sequenzialmente le interazioni tra classi per realizzare una funzionalità.
  • Collaboration Diagram: rappresenta le collaborazioni tra classi che cooperano alla realizzazione di una certa funzionalità.
  • Activity Diagram: rappresenta le attività delle classi ed la loro collocazione temporale.
  • State Diagram: rappresenta gli stati di un certo oggetto e le possibili transizioni.
  • Component Diagram: rappresenta i componenti del sistema.
  • Deployment Diagram: rappresenta l’allocazione dei componenti software rispetto ai nodi hardware.

S. E. – UML Diagrams

Modellazione Statica: alcuni esempi di UML UC diagrams

Fig. 5: DAME: redb admin Use Case (A. Nocella). Fonte: Voneural

Fig. 5: DAME: redb admin Use Case (A. Nocella). Fonte: Voneural

Fig. 6: DAME: redb session Use Case (A. Nocella). Fonte: Voneural

Fig. 6: DAME: redb session Use Case (A. Nocella). Fonte: Voneural


S. E. – UML Diagrams

Modellazione Statica: UML Class Diagram & Componeti Diagram

Fig. 7 – DAME: redb Class Diagram (A. Nocella). Fonte: Voneural

Fig. 7 - DAME: redb Class Diagram (A. Nocella). Fonte: Voneural

Fig. 8: Component Diagram. Fonte: Agile Modelling

Fig. 8: Component Diagram. Fonte: Agile Modelling


S. E. – UML Diagrams

Modellazione Dinamica: alcuni esempi di UML diagrams

Fig. 9: Sequence Diagram (A. Nocella)

Fig. 9: Sequence Diagram (A. Nocella)

Fig. 10: Collaboration Diagram. Fonte: Agile Modelling

Fig. 10: Collaboration Diagram. Fonte: Agile Modelling


S. E. – UML Diagrams

Modellazione Dinamica: alcuni esempi di UML diagrams

Fig. 11: State Chart Diagram. Fonte: Fonte: Wikipedia

Fig. 11: State Chart Diagram. Fonte: Fonte: Wikipedia

Fig. 12: Activity Diagram. Fonte: Wikipedia

Fig. 12: Activity Diagram. Fonte: Wikipedia


S.E. – Middleware

Che cos’è il middleware?!

Nonostante il nome il middleware è un software; più in generale un insieme di programmi che funge da “strato” intermedio tra diversi layer software o hardware e software… di seguito proviamo a darne una definizione:

“[...] un software di connessione che consiste in un insieme di servizi e/o di ambienti di sviluppo di applicazioni distribuite che permettono a più entità (processi, oggetti, ecc.), residenti su uno o più elaboratori, di interagire attraverso una rete di interconnessione a dispetto di differenze nei protocolli di comunicazione, architetture dei sistemi locali, sistemi operativi, ecc. ”; ovvero trattasi di Comunicazione tra processi (IPC).

da Wikipedia

S.E. – Middleware

Con il termine inglese middleware si intende un insieme di programmi che fungono da intermediari tra diverse applicazioni e componenti software. Sono spesso utilizzati come supporto per sistemi distribuiti complessi. I software utilizzati possono anche essere più di uno.
Un esempio tipico di utilizzo del middleware è il “gestore delle transazioni”, ovvero un componente che è interposto tra l’utente e il “gestore di un database”, o l’applicazione in generale, o il sistema client/server; in queste situazioni, il middleware accelera il completamento delle richieste dell’utilizzatore, riducendo, raggruppandole, il numero delle richieste di collegamento al database, e rendendo ogni collegamento il più efficiente possibile. [...]

L’utilizzo di uno strato software aggiuntivo, il middleware appunto, consente di ottenere un elevato livello di servizio per gli utenti, ed un elevato livello di astrazione per i programmatori. Inoltre, consente di facilitare la manutenzione, la stesura e l’integrazione di applicazioni. [...]

Con il termine middleware oggi si intendono una serie di strumenti come DBMS, WEB server, Application server, sistemi di gestione dei contenuti ed altri strumenti basati sul concetto di sviluppo e pubblicazione di applicazioni e contenuti. Gli sviluppi attuali si dirigono verso XML, SOAP, servizi WEB e architetture orientate al servizio. [...]

da Wikipedia

Sistemi Informativi

Cos’è un Sistema Informativo?!

In primis è un sistema: nella sua eccezione più generica, un insieme di entità connesse da relazioni. Un sistema, quindi, è un’unità, logica o fisica, costituita da diverse entità collegate tra loro e che interagiscono per raggiungere uno scopo comune.
In definitiva un sistema informativo è un sistema il cui scopo è quello di conservare informazioni garantendone l’accessibilità e l’integrità.

Un sistema informativo non è necessariamente un sistema automatico. La società umana ha imparato a gestire le informazioni ben prima dell’introduzione dell’automazione e della gestione automatica delle informazioni; si pensi alla gestione anagrafica, alla gestione delle merci, delle spedizioni, etc…

E’ possibile darne una definizione operativa: un sistema informativo di una certa attività definisce:

  • la modalità di organizzazione delle informazioni dell’attività,
  • le funzioni che si devono poter svolgere su tali informazioni per la loro gestione,
  • quali sono gli strumenti (tecnologici) da usare per realizzare l’organizzazione delle informazioni e le funzioni su di esse.

Informazione, dati e DB

Diamo alcune definizioni:

L’informazione è ciò che, per un osservatore o un recettore posto in una situazione in cui si hanno almeno due occorrenze possibili, supera un’incertezza e risolve un’alternativa, cioè sostituisce il noto all’ignoto, il certo all’incerto. In altre parole, essa riguarda il contesto in cui i dati sono raccolti, la loro codifica in forma intellegibile ed in definitiva il significato attribuito a tali dati.[...].

da Wikipedia

Un dato [...] è una descrizione elementare, spesso codificata, di una cosa, di una transazione, di un avvenimento e altro. L’elaborazione dei dati può portare alla conoscenza di un’informazione. [...]
I dati possono essere conservati e classificati sotto diverse forme: carta, supporto digitale, alfabeto, immagine, suoni e altri supporti.[...].

da Wikipedia

In informatica, il termine database, banca dati, base di dati o anche base dati, indica un archivio strutturato in modo tale da consentire la gestione dei dati stessi (l’inserimento, la ricerca, la cancellazione ed il loro aggiornamento) da parte di applicazioni software.[...].

da Wikipedia

DB e DBMS

  • Un DataBase è un insieme di informazioni.
  • Un informazione può essere composta da “sottoinformazioni” , queste possono essere suddivise in argomenti, che a loro volta possono avere delle categorie.
  • In un DataBase le informazioni sono organizzate a livello logico in tabelle, tuple e campi.
  • In un DataBase i campi rappresentano l’unità minima dell’informazione, i dati.
  • Un DataBase, oltre ai dati, contiene informazioni sulle relazioni che li legano e la loro rappresentazione.
  • Un DataBase deve garantire l’accessibilità ai dati e l’integrità delle informazioni in esso conservate.
  • Un buon DataBase non permette l’inutile duplicazione di informazioni o, in generale, la ridondanza di dati.
  • La struttura dell’organizzazione dei dati di un DataBase può essere gerarchica (come gli attualissimi DB XML), reticolare, relazionale (in assoluto i più diffusi), ad oggetti (basati sul paradigma OOP) o semantica.
  • Con il termine DataBase spesse volte ci si riferisce impropriamente ad un sistema per la gestione di DabaBase, un DBMS, DataBase Management System.
  • Un DBMS è un software che consente la creazione e la manipolazione di DB anche da più utenti.
  • Un DBMS offre la possibilità di non agire direttamente sui dati del DB ma su di una loro rappresentazione logica, astraendo totalmente la piattaforma software/hardware sottostante: un BDMS è un middleware.

Il Modello Entità Relazione

Il modello E-R

  • E’ un modello logico di rappresentazione dei dati che si basa su i concetti fondamentali di Entità e Relazione.
    Un Entità (logica) rappresenta un’informazione relativa ad un entità concreta, mentre una Relazione logica rappresenta un’informazione derivante dal legame tra due o più entità.
  • In questo modello tutte le Entità vengono rappresentate con una tabella; le Relazioni possono invece essere esplicitamente rappresentate con una tabella oppure implicitamente attraverso alcuni artifizi come l’aggiunta di un campo ad una tabella di un Entità.
  • Tutte le tabelle del modello possiedono una chiave.
  • In questo modello l’integrità dei dati viene conservata attraverso l’imposizione dei vincoli relazionali: l’insieme di questi vincoli è detto schema logico.
  • Alcuni tra i DBMS relazionali più diffusi e conosciuti: MySQL, Oracle e MS Access.
Fig. 13: DAME: redb User Entity (A. Nocella). Fonte: Voneural

Fig. 13: DAME: redb User Entity (A. Nocella). Fonte: Voneural

Fig. 14: DAME: redb Session Entity (A. Nocella). Fonte: Voneural

Fig. 14: DAME: redb Session Entity (A. Nocella). Fonte: Voneural


Un Esempio di schema E-R

  • users(email, password, name, surname, country, affiliation, status, ssid);
  • sessions(id, userId, name, experimentsNumber, creationDate, lastAccessDate);
  • experiments(id, seid, pid, name, mode, sessionId, status, creationDate, lastAccessDate, errorCode, functionality);
  • files(uri, formatName, sessionId, creationDate, modificationDate, experimentsNumber, isDownloadable, type, metadata);
  • experimentFiles(id, extension, uri, experimentId, isTotal);
  • functionalities(name, docsLink, ver, creationDate, ownName, ownMail, status, domain, fileName, trainSupported, testSupported, runSupported, fullSupported);
  • filesFormats(formatName, owner, extension, category, description);

Vincoli relazionali:

On delete users cascade on sessions, experiments, files and experimentFiles.
On delete session s cascade on experiments, files and experimentFiles.
On delete experiments cascade on experimentFiles.
[...]

Fig. 15: DAME: redb E-R Diagram (A. Nocella). Fonte: Voneural

Fig. 15: DAME: redb E-R Diagram (A. Nocella). Fonte: Voneural


SQL

SQL (Structured Query Language) è un linguaggio di programmazione per database progettato per leggere, modificare e gestire dati memorizzati in un sistema basato sul modella relazionale, per creare e modificare schemi di database, per creare e gestire strumenti di controllo ed accesso ai dati.
SQL è un linguaggio per interrogare e gestire basi di dati mediante l’utilizzo di costrutti di programmazione denominati query.[...]
Con SQL si leggono, modificano cancellano dati e si esercitano funzioni gestionali ed amministrative sul sistema dei database.[...]

da Wikipedia

Alcuni esempi di query:

1) query di creazione della tabella users:

CREATE TABLE users (email varchar(60) [primarykey], password varchar(30) [NOT NULL], name varchar(30) [NOT NULL], surname varchar(30) [NOT NULL], country varchar(30) [NOT NULL], affiliation varchar(60) [NOT NULL], status boolean [NOT NULL], ssid varchar(8) [NULL]);

2) query per la ricerca dell’affiliation del utente con email mario.rossi@inventata.it:

SELECT affiliation FROM users WHERE email=mario.rossi@inventata.it;

Esempio di riepilogo

Nel grafico sottostante è possibile individuare (cerchiati in rosso) il componente DB e il suo driver redb. Il driver accede al DB tramite il DBMS che funge da middleware. Redb implementa un’interfaccia usata dal componente FrameWork per “usare” il DB. Le informazioni arrivano all’utente finale a mezzo di file XML.

Fig. 16: DAME: project overview. Fonte: Voneural

Fig. 16: DAME: project overview. Fonte: Voneural


Le lezioni del Corso

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion