4
l'analisi, la definizione dei requisiti, il disegno software dei moduli
principali e la decomposizione dei moduli.
Nel terzo capitolo vengono trattate le metodologie e le filosofie
operative, le architetture delle applicazione ottenibili, il funzionamento
del generatore di template e del linguaggio degli script di gestione
dinamica. Questo linguaggio orientato ai dizionari di dati, è stato
studiato per creare applicazioni per piccoli database in poco tempo e in
poche righe di codice.
Il quinto capitolo descrive alcune note di pregio dell’applicazione quali:
• La facile adattabilità del generatore di template a linguaggi come
l'ASP e ad altri database;
• La possibilità di aggiungere altri generatori di template per generare
applicazioni non orientate al Web;
In appendice si trova la descrizione del PHP (linguaggio per la di
generazione dinamica di pagine HTML), un breve manuale d’uso, la
grammatica del generatore di template, una descrizione sommaria di una
libreria generica utilizzata e una visione del codice sorgente.
5
Introduzione
• Applicazioni per Database Web oriented
• Template
6
Applicazioni per Database Web oriented
La maggior parte delle applicazioni per database su web sono di piccola
dimensione principalmente limitate alla creazione di qualche form di
inserimento e qualche query, che possono essere inserite in internet o in
una intranet.
Principalmente si tratta di applicazioni commissionate a società di servizi
web da aziende specializzate in altri settori.
Benché la complessità di questi lavori sia bassa, il suo costo è comunque
rilevante poiché tiene impegnato uno o più programmatori.
Allo stato attuale il mercato non offre molti CASE per lo sviluppo rapido
di piccole applicazioni: quelli in commercio, in generale, utilizzano
template statici.
Eventuali CASE basati su template dinamici restano principalmente
utilizzati all’interno delle stesse aziende produttrici, e comunque sono
molto specifici.
7
Template
Il funzionamento base di un CASE è l’utilizzo di template.
Un template è in sostanza un codice sorgente che ha la possibilità in
alcuni punti di inserire parametri, informazioni o altro codice.
…
<Par name=”Parametro1”>
…
<Codice>
…
</Codice>
…
<Par name=”Parametro2”>
…
Figura 1:Esempio di template
8
Le grandi aziende produttrici di software progettano in proprio i loro
CASE utilizzando tipicamente template statici. Un template è statico
quando è fissato a priori. Spesso è un file, in questo caso il CASE non
deve fare altro che prendere in input i files di template e le informazioni
che devono essere incluse nel template. Il vantaggio nell’utilizzare
template statici è quello che l'utente può utilizzare il template in più
occasioni e crearne di nuovi; in generale il CASE diviene indipendente
dalle applicazioni e dai linguaggi. Questo utilizzo presenta però un
notevole svantaggio, in quanto i template essendo statici determinano
architettura rigide.
In effetti un template non è altro che un modulo di una architettura,
ovvero quest’ultima è costituita da più template.
9
Progettare architetture di applicazioni Web
• Introduzione
• Documento dei requisiti: analisi dei requisiti
• Documento dei requisiti: Definizione dei requisiti
• Disegno software: moduli principali
• Disegno software: decomposizione dei moduli
• Struttura di una pagina PHP
10
Introduzione
In questo capitolo viene presentata una metodologia di sviluppo di
architetture di applicazioni Web che gestiscono database on line. Questa
metodologia di sviluppo costituisce il modello su cui il CASE dovrà fare
riferimento. Il CASE non genera applicazioni seguendo una particolare
architettura, poiché utilizza template dinamici. L’utente impostando le
informazioni relative alla crezione dei template, determina l’architettura
software che il CASE deve fornire. Naturalmente, l’utente è vincolato
dalla metodologia di sviluppo dei template, vale a dire le architetture
diverse tra loro che possono essere generate, sono tante quanti sono i
template diversi tra loro. Quindi occorre impostare opportunamente un
metodologia di sviluppo dei template per avere un ampio insieme di
applicazioni.
Per semplicità si continuerà a parlare di architettura del sistema, in realtà
non si fa riferimento ad una particolare architettura ma ad un insieme
sostanzioso di architetture. Dove possibile, verranno specificate gli
elementi in comune, in altri casi solo caratteristiche generali.
L'architettura del sistema viene descritta utilizzando gli schemi ed i
dettami dell'ingegneria del software.
11
Documento dei requisiti: analisi dei requisiti
Sarà utilizzata un'analisi orientata ai punti di vista:
• Analisi dal punto di vista delle funzionalità;
• Analisi dal punto di vista del flusso di dati;
• Analisi dal punto di vista della caratterizzazione dei dati;
• Analisi delle tecnologie Web.
Analisi dal punto di vista delle funzionalità
Una funzionalità è un servizio che l’applicazione mette a disposizione
all’utente. L’importanza di questa analisi è che l’architettura di un
sistema dipende da quali funzionalità debba avere.
Tenuto conto che il sistema tratta applicazioni per basi di dati di piccola
e media grandezza, le funzionalità minimali riguardano servizi di:
inserimento, modifica, cancellazione ed esecuzione delle query sul
database.
L’implementazione di una funzionalità può essere decomposta in una o
più operazioni. Vediamo alcuni esempi che rigurdano semplici
funzionalità:
12
• Nell’implementazione della funzionalità di inserimento di un record
in una tabella, occorrono due operazioni: la generazione del form di
immissione dati, e l’esecuzione della query di inserimento;
• Nell’implementazione della funzionalità di modifica di un record in
una tabella, occorrono due operazioni: generazione del form di
immissione riempito dei dati del record da modificare e l’esecuzione
della query per la modifica;
• Nell’implementazione della funzionalità di cancellazione di un record
di una tabella, occorre una singola operazione: l’esecuzione della
query per la cencellazione;
• Nell’implementazione della funzionalità di effettuare un report,
occorre una singola operazione: la visualizzazione di una tabella
attraverso l’esecuzione di una query;
• Nell’ implementazione della funzionalità di effettuare una query di
archiviazione, occorre una singola operazione: l’esecuzione della
query.
13
Un’applicazione per funzionare bene, ha comunque bisogno di altri
servizi minori, qundi di altre operazioni:
• per consentire una modifica di un record, o una sua cancellazione, è
necessaria prima un’operazione che permetta di scegliere tale record.
Ad esempio una tabella di records, dove per ogni record compare un
link;
• per scegliere quale funzionalità dell’applicazione si voglia eseguire è
necessaria un’operazione di visualizzazione di un menù;
• un report, o una query archiviazione potrebbe avere bisogno di
parametri (Es: report dei tati della ditta x, dove x viene specificato
dall’utente). In questo caso ci vule ad esempio un form di
immissione dati per inserirli, oppure una tabella di records, dove per
ogni record compare un link.
14
Le funzionalità possono però crescere in complessità:
• Ricerca di un record in una tabella: occorre un’operazione di
inserimento dati e un’altra per la visualizzazione dei record..
• Immediatamente dopo aver eseguito un inserimento di un record,
viene eseguita una query di archiviazione.
• Dopo aver cancellato un record, vengono cancellati in cascata anche i
record che facevano riferimento ad esso.
Per quanto una funzionalità possa essere complessa, può comunque
essere decomposta in un insieme di operazioni base, riconducibili a:
immissione dati, visualizzazione delle query, menù.
La categoria immissione dati è caratterizzata da tutto ciò che riguarda un
modulo form, gli elementi che la costituiscono sono principalmente:
• Il link alla pagina dove inviare i dati;
• Dei controlli testo, selezione o check box dove inserire i dati;
• Un bottone per inviare i dati.
15
Figura 1: Esempio di operazione di immissione dati
La categoria visualizzazione delle query è caratterizzata dall'esecuzione
delle query, gli elementi che la costituiscono sono principalmente:
• una o più query;
• una o più tabelle dove visualizzare i risutati.
Figura 2: Esempio di operazione di visualizzazione delle query
16
La categoria menù è caratterizzata da menù di scelte.
Figura 3: Esempio di operazione di visualizzazione di menù
Possiamo notare che le tre categorie si differenziano sia per quanto
riguarda la parte dell'interfaccia grafica e sia per il codice occorrente per
l'implementazione.
17
Analisi dal punto di vista del flusso di dati
Figura 4: Diagramma di flusso di un’applicazione Web per basi di dati
Prendendo a riferimento la Fig. 4 analizziamo i flussi di informazione
che vengono generati alla richiesta di una pagina sul Web.
Dal browser parte la richiesta, il server la intercetta, quindi prende la
pagina PHP e la elabora. L’elaborazione genera una pagina temporanea
con tag HTML e la invia al browser che ha effettuato la richiesta. Il
server offrendo il servizio a più utenti, non può mantenere le variabili
riguardanti le pagine PHP processate eccetto nella gestione dei Cookies
o delle sessioni.
I Cookies, non possono superare il centinaio di byte; e solo nelle nuove
versioni di PHP, il server gestisce una sessione (temporanea) dove
mantiene tutte le variabili.