Caricare documenti e articoli online 
INFtub.com è un sito progettato per cercare i documenti in vari tipi di file e il caricamento di articoli online.


 
Non ricordi la password?  ››  Iscriviti gratis
 

LA PROGETTAZIONE DEL SOFTWARE - concetti di base

informatica





I.T.C.

"Lucio Lombardo Radice"

Roma











LA PROGETTAZIONE DEL SOFTWARE




Indice generale.


Introduzione .......................... pagina 3

concetti di base ..........................4

1.1. Il problema .......................... 4

1.2. Il ciclo di vita del Software .................... 4

2. L'analisi .......... ..... ...... 5

2.1. Lo studio di fattibilità ......................5   2.2. L'analisi del problema .....................5 2.2.1. Descrivere il sistema................... 6

2.2.2. Identificare le entità, gli attributi, i domini, le relazioni..... 9

3. Il disegno della soluzione........................ 14

3.1. Il disegno degli archivi .................... 15

3.2. l'architettura funzionale.................... 17

3.3. un esempio di specifiche funzionali................ 18

3.4. Il disegno dettagliato..................... 18

Appendice 1: La programmazione ad eventi................ 21

1.Dalla programmazione procedurale alla programmazione ad eventi... 21

2.La documentazione di un progetto Visual Basic............. 23

Appendice 2: La progettazione dell'ipermedia ................25

Multimedialità e ipertesti ..................... 25

La multimedialità ...................25

Gli ipertesti ......................26

Gli ipermedia ....................26

2. Gli elementi di un ipermedia ..................27

2.1. La struttura........................27

2.2. Il Layout ........................28

2.3. Il colore e gli sfondi....................29

2.4. Il carattere .........................29

3. La progettazione dell'ipermedia....................30

3.1. le fasi della progettazione.................30

3.2. lo studio di fattibilità ..................30

3.3. lo studio del sistema...................30

3.4. la macroanalisi......................31

3.5. la microanalisi ....................... 31

3.6. la realizzazione ....................32

4. Un esempio ...........................32

Bibliografia ............................ 37





Introduzione.


Questa trattazione è diretta agli studenti di un triennio Mercurio ed illustra una metodologia di progettazione del Software, semplice da acquisire e facilmente utilizzabile, pur rimanendo rigorosa. Per brevità di trattazione (non lo diciamo come quelli che, non essendo esperti di un argomento, lo trattano in maniera eccessivamente superficiale), il testo non è certamente esaustivo del tema. Consigliamo agli studenti che volessero saperne di più (!) di consultare qualcuno dei testi elencati in bibliografia.

Ovviamente si è cercato di esporre gli argomenti con un linguaggio lineare e nel modo più chiaro possibile, in modo da rendere il testo rapid 737j95h amente fruibile (ed anche per fare in modo che non finisca subito cestinato). Nello stesso tempo, però, si è cercato di non incorrere in eccessive semplificazioni, che avrebbero condotto alla banalità e, dunque, alla inutilità del trattato. Ai lettori dedichiamo il seguente brano, scritto da qualcuno più importante di noi, come spunto per una iniziale riflessione:

"La prima regola è di non accettare mai nulla per vero prima di convincermi che sia tale con evidenza: di evitare, cioè, attentamente la fretta e la prevenzione e di non includere nulla nei giudizi al di là di ciò che appaia alla mia mente tanto chiaramente e distintamente da allontanare qualunque dubbio.

La seconda regola è di distinguere ogni problema da esaminare in tante parti più piccole, quanto sia possibile e indispensabile per risolverlo in modo migliore.

La terza regola è di indagare ordinatamente, cominciando dalle cose più semplici e più comprensibili, per risalire, per gradi, a poco a poco, fino alla comprensione delle più complesse, presupponendo un ordine anche tra quelle cose che non si trovano naturalmente le une prima delle altre.

La quarta regola è di fare sempre degli elenchi tanto completi e delle revisioni tanto generali da poter essere certo di non aver dimenticato nulla."


Cartesio, Discorso sul metodo, 1637















Concetti di base.




1.1. Il problema.


Che cos'è un problema? Si tratta di una situazione in cui si presentano uno o più quesiti, ai quali si desidera dare una risposta. Ad esempio: se un triangolo rettangolo ha l'ipotenusa di 5 cm e un cateto di 4 cm, quanto è lungo l'altro cateto? Questo è un problema matematico di facile soluzione, poiché si conosce la formula risolutiva, fornita dal teorema di Pitagora. Non sempre, però, la soluzione del problema è così immediata! Facciamo ora un esempio di un tipico problema che si presenta a chi lavora nell'ambito della progettazione del Software: un'azienda commerciale che si occupa di vendita all'ingrosso di articoli di profumeria, con ordini telefonici da parte del cliente o tramite venditori, desidera una procedura automatizzata che consenta di gestire l'evasione degli ordini, con stampa della fattura e controllo delle merci sottoscorta per sollecitare l'approvvigionamento ai propri fornitori.. Come si può facilmente capire, non c'è alcuna formula che mi permetta di risolvere un simile problema. Quello che si può fare, però, è stabilire una metodologia per procedere nella risoluzione, che sia abbastanza rigorosa per ottenere un prodotto efficace ed efficiente, ma anche abbastanza semplice per evitare al progettista perdite di tempo. Ovvero una metodologia che consenta di soddisfare il cliente (nel nostro ambito: i docenti), ma che nel contempo non faccia impazzire progettisti e realizzatori (nel nostro ambito: gli studenti).




1.2. Il ciclo di vita del Software.


Per ciclo di vita del Software si intende il periodo che va dal momento in cui nasce l'esigenza di automatizzare una funzione al momento in cui il prodotto realizzato diventa obsoleto o non più utilizzabile.

Le fasi del ciclo di vita del Software sono:

lo studio di fattibilità;

l'analisi del problema;

il disegno della soluzione;

la realizzazione;

i test di validazione;

l'uso e la manutenzione.


Ciascuna di queste fasi prevede una precisa documentazione, che farà da supporto alle fasi successive. Tale documentazione dovrà essere costantemente aggiornata ogni qualvolta si apporteranno modifiche, durante tutta la vita del prodotto. Inoltre occorrerà stilare un manuale d'uso per l'utente, che lo guidi puntualmente nel lavoro quotidiano.

In questa trattazione ci occuperemo dei punti 2 e 3, accennando solo brevemente al punto 1. Per gli altri punti rimandiamo ai libri di testo.





L'analisi.



2.1. Lo studio di fattibilità.

È la fase preliminare. Avvertita la necessità del progetto, si devono individuare con precisione:

gli obiettivi;

le funzioni da realizzare;

le risorse disponibili;

il destinatario del prodotto;

i tempi di realizzazione;

i costi;

le fasi in cui si articolerà il progetto, dettagliando, per ciascuna fase, i tempi di attuazione, le risorse impegnate, il tipo di attività, il prodotto ottenuto.


Il documento risultante costituirà la base del progetto, da cui si procederà per raffinamenti successivi, per ottenere specifiche sempre più dettagliate.

Occorre sottolineare che questa fase viene generalmente espletata da parte di uno staff di esperti aziendali ed informatici (ed è per questo che non ci sogneremmo mai di richiederla ai nostri studenti).




2.2. L'analisi del problema.


In questa fase si dovrà attentamente studiare la realtà (cosa il problema è) in cui è nata l'esigenza di automazione, (oppure l'esigenza di rivedere procedure già esistenti), prescindendo dalla tecnologia che sarà impiegata per l'implementazione. Occorre a questo punto ricordare il significato di un termine che useremo in seguito. Per "sistema" si intende quella parte significativa della realtà, in cui si ambienta il nostro problema. Per meglio dire, un sistema è un insieme di elementi che interagiscono fra loro e con l'esterno in funzione di un obiettivo comune. Possiamo così riassumere i passi da seguire per effettuare l'analisi:


descrivere dettagliatamente il funzionamento dell'ambiente (sistema) nel quale si deve operare;


disegnare l'architettura funzionale del sistema;


identificare gli oggetti significativi per il problema, cioè le entità, le loro caratteristiche, cioè gli attributi, l'insieme dei loro possibili valori, cioè i loro domini di definizione e, infine, le relazioni fra le entità.


Dettaglieremo ora il procedimento da seguire per rispondere ai singoli punti.




2.2.1. Descrivere il sistema.


Per descrivere il funzionamento del sistema ci si può avvalere di una descrizione verbale o di un disegno che rappresenti le operazioni eseguite ed i flussi informativi all'interno del sistema (modello intuitivo della realtà).

Nell'eventuale descrizione verbale occorrerà mettere in luce gli aspetti del problema che necessitano di approfondimento. Si suggerisce di:


descrivere l'utilizzatore finale del prodotto, evidenziando, nel caso di un'azienda, le sue caratteristiche generali;


descrivere i documenti cartacei in uso presso l'utente, evidenziando come essi vengono usati;


descrivere le modalità di svolgimento di ciascuna funzione;


evidenziare i possibili sviluppi futuri.


Il documento risultante da questa fase è la macroanalisi, una relazione discorsiva, abbastanza snella ma esauriente, presupposto fondamentale per disegnare l'architettura di sistema e stilare l'analisi funzionale.


Volendo disegnare un modello sintetico del funzionamento del sistema, utilizzeremo una simbologia standard:








Rappresenta un documento






Rappresenta una funzione







Rappresenta un archivio








Rappresenta un soggetto esterno al sistema

Che fornisce un INPUT o ottiene un OUTPUT





Ad esempio, supponiamo di voler rappresentare una parte della situazione problematica esposta al punto 1. Il disegno risultante è il seguente:











UFFICIO VENDITE

Registrazione ordini

 


ORDINI

 

CLIENTE

 

ORDINE

 

MERCI

 











EVADIBILE?

  SI NO






FATTURA

 

CLIENTE

 

UFFICIO ACQUISTI

 

FATTURE

 

ORDINI

 









In questa fase, naturalmente, si avranno a disposizione tutti i modelli di documenti circolanti all'interno dell'azienda, quelli ricevuti dall'esterno e quelli emessi dall'azienda verso l'esterno, necessari per descrivere il funzionamento del sistema. In un caso reale i dati presenti su tali documenti sarebbero catalogati in un elenco, suddivisi in dati di INPUT, di OUTPUT e di ELABORAZIONE, nelle nostre simulazioni normalmente i dati sono in quantità limitata, basterà avere a disposizione il materiale necessario per rispondere ai punti 2 e 3.



2.2.2. Identificare le entità, gli attributi, i domini, le relazioni.


2.2.2.1. le entità.


Le entità del sistema sono le classi di oggetti del mondo reale che abbiano esistenza propria e siano significativi per il sistema stesso; gli attributi sono le proprietà delle entità, ciascuno dotato di un descrittore, il nome; il dominio dell'attributo è l'insieme dei valori possibili per l'attributo. Ciascuna entità ha più occorrenze, date da tutti i possibili oggetti appartenenti all'entità stessa. Per chiarire questi concetti facciamo subito un esempio. L'azienda ha dei clienti, ciascuno dei quali è individuato dal suo nominativo, ecc. L'entità è CLIENTE, gli attributi sono (NOMINATIVO, INDIRIZZO, CITTA, CAP, PROVINCIA, TELEFONO,.), i valori dei singoli attributi sono:



NOMINATIVO

INDIRIZZO

CITTA

CAP

PROVINCIA

TELEFONO


Rossi Mario

Via Po,32

Roma


RM



Verdi Ugo

Via Modena,21

Roma


RM



Neri Giulio

Via Fiume,89

Milano


MI












Ciascuna riga della tabella rappresenta un'occorrenza dell'entità CLIENTE e ciascuna colonna contiene i valori di un attributo.

Ma come si fa a capire se un oggetto è significativo, cioè se esso è un'entità del sistema? Semplice: si elencano i suoi attributi. Se tali attributi sono presenti nei documenti aziendali, se servono per rispondere ai quesiti, se devono essere comunicati all'esterno, allora l'oggetto è un'entità del sistema.

Oppure, si può procedere in senso inverso. Si elencano tutti i dati presenti sui documenti, li si raggruppa per omogeneità di proprietario (l'oggetto), si individuano le classi di oggetti e si ottengono le entità. Facciamo un esempio, sempre riferito al caso della gestione degli ordini.



DOCUMENTO ORDINE:

numero dell'ordine;

data dell'ordine;

v  tipologia dell'ordine;

rap129    codice del venditore;

Bianchini   cognome del venditore;

Mario nome del cliente;

Rossi  cognome del cliente;

Via Po,32-Roma indirizzo del cliente;

RSSMRA55H12H501J    codice fiscale del cliente;

prima riga dell'ordine:

456y  codice della 1° merce;

shampoo "WELL" descrizione della 1° merce;

numero pezzi ordinati;

prezzo unitario 1° merce;

importo 1° merce;

percentuale IVA 1° merce;

importo IVA 1° merce;

importo con IVA 1° merce;

seconda riga dell'ordine:

567x  codice della 2° merce;

descrizione della 2° merce;

numero pezzi ordinati;

prezzo unitario 2° merce;

importo 2° merce;

percentuale IVA 2° merce;

importo IVA 2° merce;

importo con IVA 2° merce;


ecc.


Dall'esame dei dati fin qui elencati possiamo ricavare l'esistenza delle seguenti entità: ORDINE, CLIENTE, MERCE, VENDITORE. Proseguendo con questo metodo si individueranno tutte le entità e tutti gli attributi. Per stabilire il dominio degli attributi occorrerà un esame attento di tutti i valori presenti sui documenti.

le relazioni.


Una relazione è un'associazione logica fra due entità. Questo vuol dire che se pensiamo agli insiemi costituiti dalle occorrenze di due entità, a ciascuna occorrenza del primo insieme corrisponde una o più occorrenze del secondo insieme. Ad esempio, nel caso che stiamo esaminando a ciascuna occorrenza CLIENTE corrisponderanno più occorrenze ORDINI. Le relazioni non sono tutte uguali, ma si possono classificare come segue:



relazioni totali: ad ogni occorrenza del primo insieme corrisponde almeno un'occorrenza del secondo insieme;


relazioni parziali: a qualche occorrenza del primo insieme non corrisponde alcuna occorrenza del secondo insieme;


relazioni univoche: ad ogni occorrenza del primo insieme corrisponde al più un'occorrenza del secondo insieme;


relazioni multiple: ad ogni occorrenza del primo insieme corrispondono una o più occorrenze del secondo insieme.



Facciamo qualche esempio: la relazione che ad una classe associa i suoi alunni è totale e multipla; la relazione che ad una persona associa il coniuge è parziale, in quanto ci sono persone non coniugate; la relazione che ad una persona associa la sua città di residenza è univoca.

Un'altra possibile classificazione, in base alla cardinalità, è la seguente:


relazioni biunivoche: ad ogni occorrenza del primo insieme corrisponde una ed una sola occorrenza del secondo insieme, cioè la diretta e l'inversa sono univoche (1:1);


relazioni semplici: ad ogni occorrenza del primo insieme corrispondono più occorrenze del secondo insieme, ma ad ogni occorrenza del secondo insieme corrisponde una ed una sola occorrenza del primo insieme, cioè la diretta è multipla e l'inversa è univoca (1:N);


relazioni complesse: ad ogni occorrenza del primo insieme corrispondono più occorrenze del secondo insieme e viceversa, cioè sia la diretta che l'inversa sono multiple (N:M).


Un esempio di relazione biunivoca è quella che ad un'auto associa il suo libretto di circolazione; un esempio di relazione semplice è quella che ad una classe associa i suoi alunni; un esempio di relazione complessa è quella che ad un docente associa i suoi alunni. Le relazioni 1:N vengono dette, nel linguaggio comune, padre-figlio, poiché hanno le caratteristiche di tale relazione, esistente in natura. Cercheremo ora di fornire, dopo le rigorose definizioni, consigli di tipo pratico.


Se su di un documento aziendale compaiono dati di più entità, queste sono certamente in relazione. Esaminiamo i documenti relativi agli ordini: su ciascun documento troviamo dati del cliente e dati dell'ordine; su più documenti troveremo dati dello stesso cliente, ma i dati dell'ordine sono diversi; questo vuol dire che la relazione CLIENTE-ORDINE è una relazione semplice. Su ciascun ordine, relativo ad un cliente, troveremo elencate più merci, ma su ordini diversi, relativi a clienti diversi, possiamo trovare la stessa merce: questo vuol dire che la relazione ORDINE-MERCE è una relazione complessa.




2.2.2.3. Le chiavi.


Occorre, a questo punto, un'ulteriore riflessione. Nelle nostre elaborazioni avremo a volte bisogno di individuare una determinata occorrenza di un'entità, e occorrenze di un'altra entità che sono in relazione con questa. Ci serve qualcosa, una specie di "marchio", che ci permetta di riconoscere le occorrenze e le relazioni. Così, come ognuno di noi ha un cognome e ad un figlio si attribuisce il cognome del padre, noi dovremmo poter attribuire un "cognome" alle entità figlie di altre entità. Tale "cognome", però, deve essere univoco (cioè non deve esisterne un altro uguale) e minimale (deve essere il più breve possibile, per evitare errori e perdite di tempo). Un tale attributo si chiama chiave primaria.

Non sempre esiste un attributo naturale dell'entità (che descrive caratteristiche innate, come il peso per una merce o il cognome per un cliente) che sia in grado di individuare univocamente un'occorrenza. Sappiamo, però, che esistono attributi non naturali che vengono forzatamente assegnati ai soggetti proprio per questi scopi: ad esempio il codice fiscale o la partita IVA per un cliente, il codice a barre per una merce. Per concludere, quando avremo bisogno di una chiave primaria, se non ci sono attributi naturali utili a questo scopo ne "inventeremo" uno. Assegneremo, cioè, a ciascuna occorrenza un numero progressivo e lo inseriremo fra gli attributi. Questo sarà la nostra chiave primaria.

Ora vi starete chiedendo: è sempre necessario avere una chiave primaria per le entità? No, ne potremmo fare a meno per quelle entità che non sono "padre" in alcuna relazione, ma è una buona abitudine che una chiave ci sia sempre.

Ma dovendo ricercare un soggetto, come si fa a ricordare un tale attributo? Impossibile! Dovendo ricercare una merce, non ricorderemo mai il suo numero d'ordine, ma naturalmente ricorderemo come si chiama. La descrizione della merce, pur non potendo essere una chiave primaria (perché non univoca e non minimale), costituisce un valido strumento di accesso ai dati. Un simile attributo si chiamerà chiave alternativa o chiave secondaria. Ad un'entità attribuiremo al più una chiave primaria, ma potremo attribuire più chiavi secondarie, quante ne occorrono per accelerare le nostre ricerche. Ma che non vi venga in mente di esagerare! In fase di realizzazione, infatti, troppe chiavi secondarie appesantiscono le elaborazioni.




2.2.2.4. Il diagramma entità-relazioni.


Le entità, gli attributi e le relazioni presenti nel sistema possono essere rappresentati con uno schema, il diagramma entità-relazioni, che riassume sinteticamente tutte le informazioni necessarie per la descrizione del sistema. I simboli da utilizzare sono i seguenti:




 


ENTITÀ




ATTRIBUTO




CHIAVE PRIMARIA




RELAZIONE





Ad esempio, per descrivere la relazione CLIENTE-ORDINE si può utilizzare lo schema:






EMETTE

 

CLIENTE

 

ORDINE

 
PROGCLI COGNOME NOME . NUMEROORD DATAORD ... N




A questo punto occorre sottolineare un'importante caratteristica delle relazioni complesse. Osserviamo, ad esempio, la relazione ORDINE-MERCE.





MERCE

 

ORDINE

 

CONTIENE

 
N M





In una tale associazione occorre mettere in relazione un ordine con tutte le merci che contiene; ma occorre anche mettere in relazione una merce con tutti gli ordini che la contengono. Per ottenere questo risultato si identificherà una nuova entità, la RIGAORDINE, (coincidente con la relazione "CONTIENE"), che potrà essere dotata o meno di attributi naturali (in questo caso, il numero di riga e la quantità ordinata).

Il disegno che risulterà da questa fase è lo schema concettuale, che definisce la struttura logica del sistema secondo un modello astratto, cioè senza tenere conto delle modalità con cui il sistema sarà meccanizzato.






3. Il disegno della soluzione.


In questa fase si dovrà delineare la soluzione informatica al problema proposto. In particolare occorrerà produrre:


il disegno degli archivi;

l'architettura dei moduli;

le specifiche funzionali;

il disegno dettagliato delle fasi.


A questo punto saranno già state determinate le risorse Hardware e Software necessarie alla realizzazione delle procedure informatiche, dunque il progettista dovrà tenere conto dei vincoli e delle potenzialità di tali risorse. In questa trattazione si supporrà di disporre di:

personal computer con sistema operativo Windows;

Software: Office e Visual Basic (dando per scontato che i nostri lettori conoscano questi prodotti).

Analizziamo ora in dettaglio ogni singolo punto.




3.1. Il disegno degli archivi.


In questa fase definiremo lo schema logico dei dati, cioè daremo una descrizione dei dati e delle relazioni realizzata tenendo conto di un modello di dati. Per una rigorosa trattazione sui modelli si rimanda al corso di teoria. Ci limitiamo a dire che il modello che qui si utilizza è quello relazionale, che permette di descrivere i dati e le associazioni fra i dati in forma di relazione. Una relazione è rappresentata con una tabella formata da tante righe quante sono le occorrenze dell'entità e da tante colonne quanti sono gli attributi dell'entità. Per la rappresentazione delle relazioni si possono seguire le seguenti indicazioni:


relazioni biunivoche: A r B; normalmente le due entità in relazione confluiscono a formare un'unica tabella, a meno che le specifiche del problema non siano tali da rendere necessaria, per una maggiore efficienza delle elaborazioni, la creazione di due tabelle distinte, nel qual caso su ciascuna si riporterà la chiave primaria dell'altra;


relazioni semplici: A r B; in questo caso si genereranno due tabelle, duplicando sulla tabella B la chiave primaria della tabella A. Se però ci si accorge che la tabella A è costituita da un solo attributo, o anche da due, ma di piccole dimensioni, potrebbe essere più conveniente strutturare solo la tabella B, aggiungendovi gli attributi di A. Una tale duplicazione di dati, pur non essendo concettualmente corretta, può essere giustificabile per motivi di maggiore efficienza delle elaborazioni;


Relazioni complesse: A  R B; in questo caso si genereranno tre tabelle, ricordando che per stabilire la relazione occorre che la tabella R contenga le chiavi primarie di A e di B.


In tutti e tre i casi, se la relazione è totale si stabilirà di applicare l'integrità referenziale, cioè il vincolo di non poter inserire un record "figlio" senza la presenza del "padre". Se la relazione è parziale faremo a meno di tale vincolo.

Riflettiamo ora brevemente sui i concetti fondamentali relativi agli archivi tradizionali, e sulla relativa terminologia. Ricordiamo che un record logico è un insieme di dati, tra loro generalmente disomogenei, riferiti ad uno stesso soggetto, che si succedono in un ordine precostituito. I singoli dati, contenuti nel record, si chiamano campi. Un archivio è un insieme di record omogenei, registrati su un supporto di memoria di massa. Ovvero, un archivio è un file (nel senso classico del termine: insieme di byte registrati con continuità su un supporto di memoria, a cui è associato un nome) contenente dati riferiti a soggetti omogenei, ordinati per soggetto. La riga della tabella, dunque, è un record logico, un attributo della tabella è un campo e la tabella è un archivio. A questo punto il Data Base, cioè la raccolta dei dati relativi all'intero sistema, sarà costituito da un insieme di tabelle poste in relazione fra loro.

Vediamo ora come si descrive una tabella. Ricolleghiamoci al nostro esempio. È stata individuata un'entità CLIENTE, i cui attributi sono NOMINATIVO, INDIRIZZO, CITTA, CAP, PROVINCIA, TELEFONO, CODICEFISCALE .. Occorre tenere presente che in un DB ciascun attributo deve essere elementare, o perlomeno devono essere elementari quegli attributi che saranno oggetto di interrogazioni. Così, nell'ipotesi che si desiderino elenchi di clienti ordinati per provincia, sul tracciato deve comparire un campo PROVINCIA. Se invece si rinuncia a un tale campo, conglobandolo, ad esempio, nel campo RESIDENZA, si dovrà rinunciare ad una tale opportunità.

A questo punto possiamo disegnare il tracciato record CLIENTE:



CLIENTE (PROGCLI, NOMINATIVO, INDIRIZZO, CITTA, CAP, PROVINCIA, TELEFONO, CODICEFISCALE .)



La sottolineatura di PROGCLI significa che questo è il campo chiave, contenente un progressivo numerico che, nell'ambito di ACCESS, sarà automaticamente calcolato. Dopo aver disegnato il tracciato, descriveremo i singoli campi, come segue:



NOME CAMPO

TIPOLOGIA

DIMENSIO-NE

DESCRIZIONE

OBBLIGA-TORIO

INDICIZ-ZATO

PROGCLI

CONTATORE


Progressivo (chiave)

SI


NOMINATIVO

TESTO


Cognome e Nome

SI

SI

INDIRIZZO

TESTO


Via e num. civico

SI

NO

CITTA

TESTO


Comune residenza

SI

NO








Per le ulteriori specifiche di ciascun dato, all'atto della strutturazione delle tabelle ACCESS si seguiranno le indicazioni fornite dall'interfaccia dell'applicativo.

Non occorrerà molta fatica (per fortuna!) per descrivere lo schema fisico del Data Base, cioè per definire le caratteristiche dei files, la loro organizzazione, il formato dei record fisici. Basterà dichiarare in quale cartella si vuole inserire il DB, dargli un nome, creare la struttura logica delle tabelle e dare loro un nome. L'allocazione dei dati è a totale carico del File System, che comunica con il DBMS in modo assolutamente trasparente non solo per l'utente ma anche per il progettista. Per chi volesse approfondire la questione (!), rimandiamo ai manuali specifici.




3.2. L'architettura funzionale.


L'architettura di sistema o architettura funzionale è un disegno che rappresenta in forma di albero tutte le funzioni espletate all'interno del sistema ed i legami di dipendenza gerarchica esistenti fra esse. Un tale disegno permette di realizzare la soluzione in modo più semplice, poiché le singole parti di cui si compone l'architettura possono essere realizzate singolarmente ed infine assemblate. Un tale metodo si definisce top-down. Va sottolineato che questo modo di operare potrebbe non essere sempre attuabile nella realtà, in relazione all'ampiezza del sistema, alla complessità del problema ed all'integrazione fra le funzioni aziendali. Nelle nostre simulazioni, tuttavia, questo metodo è quasi sempre il più idoneo strumento di descrizione delle funzioni aziendali. Si tratterà, al più, di sottolineare le funzioni che sono integrate fra loro, per non commettere errori in fase di sviluppo delle procedure. Nel caso che stiamo esaminando, potremmo disegnare la seguente architettura funzionale:






GESTIONE VENDITE

 

GESTIONE ACQUISTI

 










Nel disegnare l'architettura funzionale si procederà nel dettaglio fino a quando si ottengano funzioni chiaramente identificabili, coincidenti in genere con un programma. Per concludere, si suggerisce di corredare sempre il disegno con una spiegazione verbale, (specifiche funzionali) in cui si chiarisca tutto ciò che non si evince direttamente dallo schema. In particolare, per ciascuna funzione, si descriverà:

chi la esegue;

quando;

perché;

qual è la modalità operativa (interattiva o batch);

quali archivi usa e quali dati di ciascun archivio;

quali dati devono essere inseriti dall'operatore;

qual è l'output;

qual è l'interfaccia;

con quali funzioni essa è collegata, cioè se ci sono operazioni che debbono essere svolte prima o dopo.


3.3. Un esempio di specifiche funzionali.


Modulo: GESTIONE CLIENTI:


2. 3. la funzione sarà eseguita dall'ufficio vendite ogni qual volta è necessario inserire un nuovo cliente, variare i dati di un cliente, cancellare un cliente, visualizzare i dati di un cliente;

è una funzione interattiva;

si utilizzerà la tabella CLIENTI, con tutti i suoi campi;

per la funzione di inserimento l'operatore inserisce tutti i dati, tranne il codice che è un progressivo automatico; per la funzione di variazione l'operatore inserirà i dati che desidera variare; per la cancellazione basterà dare la conferma;

in output avremo la tabella CLIENTI aggiornata;

l'interfaccia è costituita da una maschera contenente i campi della tabella CLIENTI e opportuni pulsanti che consentano di effettuare o confermare le operazioni: INSERISCI, VARIA, CANCELLA, STAMPA;


3.4. Il disegno dettagliato.


In questa fase occorrerà dettagliare ciascuna fase, per poter procedere alla realizzazione. In particolare occorrerà descrivere dettagliatamente:


Il diagramma di flusso dei dati;

Le maschere, allegando una spiegazione;

gli oggetti presenti sulle maschere;

gli eventuali tabulati di stampa;

i dati d'archivio necessari all'elaborazione;

eventuali variabili di memoria necessarie all'elaborazione;

le procedure.


Facciamo un esempio.



Modulo: GESTIONE CLIENTI


l'archivio necessario per realizzare la funzione è CLIENTI.



Il diagramma di flusso dei dati è il seguente:












(la doppia freccia verso l'archivio indica che lo si aggiorna).



la maschera utilizzata è la seguente:


GESTIONE CLIENTI

 
FORMCLI




PROGRESSIVO

 

 

 

NOMINATIVO

 

INDIRIZZO

 

 

 

 

 

 

















Occorrerà ora descrivere gli oggetti presenti sulle maschere, con particolare cura per i pulsanti, dettagliandone la funzione. Ad esempio:





Nome oggetto



Evento associato

Metodo (azioni associate)

CMDINSERISCI

click

Aggiunge il record

CMDVARIA

click

Varia il record

CMDCANCELLA







Lo stesso si farà per tutti i pulsanti e per gli oggetti la cui interpretazione non sia evidente (cioè: non perdete tempo a dire che l'etichetta vicino alla casella di testo contiene la scritta "inserisci il nominativo del cliente...", perché è ovvio!)


descriveremo ora il formato della stampa che si ottiene premendo il pulsante STAMPA:



REP1CLI






















per ciò che concerne i dati di archivio utilizzati, non lasciatevi ingannare dal fatto che in questo caso siano tutti quelli della tabella CLIENTI, poiché capiterà, a volte, di usare solo alcuni dei campi di una tabella e, in tal caso, lo dichiareremo.

Non ci sono, in questo caso, variabili di memoria aggiuntive.


le procedure già comprese nell'applicativo ACCESS sono sufficienti a risolvere il problema, senza necessità di programmazione. Volendo dettagliare maggiormente questo punto diremo che : occorrerà, in primo luogo, strutturare una QUERY parametrica che consenta di visualizzare i dati di un certo cliente. L'SQL relativo è il seguente:


SELECT clienti.progcli, clienti.nominativo, ....

FROM clienti

WHERE [[clienti.Nominativo]=["dammi il nominativo"]]


L'interfaccia sarà disegnata come maschera di ACCESS, in modo guidato. In MODALITÀ STRUTTURA, poi, si aggiungeranno i pulsanti, assegnando le funzioni specifiche in modo interattivo. Il codice VISUAL BASIC relativo al pulsante INERISCI, ad esempio, sarà il seguente:


Private Sub cmdinserisci_Click()


DoCmd.GoToRecord , , acNewRec


Exit_cmdinserisci_Click:

Exit Sub


Appendice 1: La programmazione ad eventi.


Di Giuseppe De Pietro e Maria Di Lillo


Dalla programmazione procedurale alla programmazione ad eventi.


La programmazione procedurale si è avvalsa di strumenti, i linguaggi di programmazione, che si sono evoluti nel tempo per facilitare il lavoro del programmatore. Si è passati così dalla primordiale programmazione in linguaggio macchina, in cui il programmatore, utilizzando il rigido formato delle istruzioni e gli indirizzi reali di memoria, doveva essere non solo espertissimo, ma anche molto paziente, alla programmazione in assembler, in cui poteva perlomeno utilizzare i nomi al posto degli indirizzi di memoria, restando sempre però vincolato al tipo di elaboratore su cui lavorava, e, infine, alla programmazione con linguaggi evoluti, tipo il COBOL, il FORTRAN, IL BASIC, il PASCAL, ecc., in cui, finalmente svincolato dalla macchina, il programmatore poteva "parlare" un linguaggio più simile al suo, rendendo più brevi sia i tempi di realizzazione del programma, che quelli della messa a punto. Ma, ahimè, l'uomo non si accontenta mai, e, raggiunto il risultato di migliorare le condizioni di vita del programmatore, si è dedicato a migliorare quelle dell'utente. Questo individuo, spesso trascurato in passato, ricopre in realtà un ruolo fondamentale per la buona riuscita del lavoro, poiché è lui che, utilizzando le procedure, ne decreta il successo o il fallimento.

Nella programmazione procedurale il programmatore traduceva l'algoritmo risolutivo in un linguaggio di programmazione, generando un codice composto di istruzioni da eseguire in sequenza, quindi imponeva all'utente le azioni da svolgere e l'interfaccia, di tipo testuale, seguiva le esigenze e i limiti della programmazione. L'esecuzione del programma, dunque, avveniva secondo il rigido schema configurato in fase di analisi e programmazione e l'utente non poteva intervenire durante l'esecuzione, se non per inserire i dati richiesti dal programmatore.

La diffusione dei Personal Computer, di costo moderato e uso facilitato, lo sviluppo della grafica e la disponibilità di strumenti come il mouse hanno messo in crisi questo modello di programmazione procedurale: nello sviluppo del Software si è intrufolata la democrazia! L'imperatore programmatore ha dovuto cedere parte del suo potere ai bisogni capricciosi dell'utente, che, mouse in pugno, decide i tempi e l'ordine di esecuzione delle procedure.

Gli applicativi, realizzati in forma standard per un mercato vasto e spesso non ben identificato, devono adattarsi ad un utente imprecisato, sconosciuto al programmatore, che non può contare sulla sua influenza e sul suo prestigio per far sì che l'utente si adatti al suo modo di ragionare. Nascono così nuovi linguaggi, più versatili, che usano la grafica e si basano sui concetti di oggetto e di evento: il primo termine si riferisce ad ogni elemento che compone l'interfaccia; il secondo ad un'azione esterna che l'oggetto riconosce, eseguendo un metodo, cioè un'insieme di istruzioni. Il programma, dunque, non sarà eseguito in sequenza, ma in base alle azioni che l'utente eseguirà dall'esterno. Questo nuovo modo di pensare, tipico dell'ambiente Windows, si è affermato per la gradevolezza delle interfacce e per la facilità d'uso delle applicazioni, che non perdono, tuttavia, di efficacia ed efficienza.




La documentazione di un progetto Visual Basic.


Alla base di un progetto Visual Basic ci sono i Form, cioè le maschere che costituiscono l'interfaccia, di tipo grafico, fra il programma e l'utente. Dunque la documentazione inizierà con un disegno accurato delle maschere che compongono il progetto. Ciascuna maschera conterrà oggetti di vario genere, ciascuno dotato delle sue proprietà, i cui valori sono assegnati per default dal Software. Naturalmente, alcuni di questi valori saranno cambiati dal programmatore. Ad esempio, normalmente si sostituirà il nome assegnato automaticamente agli oggetti con uno mnemonico, che ne individui il tipo e la descrizione. Supponiamo di dover risolvere il seguente problema:


Si vuole realizzare un progetto per un'agenzia di viaggi, che fornisce pacchetti per visite d'istruzione a Parigi. Al cliente viene richiesto: la denominazione, l'indirizzo, il numero di partecipanti, il mezzo di trasporto, il numero di giorni. I viaggi in treno costano £ 400000 più £ 70000 al giorno per il soggiorno ed i mezzi di trasporto, i viaggi in pullman costano £ 500000 più £ 50000 al giorno per il soggiorno ed i mezzi di trasporto. Calcolare il costo totale e il numero di gratuità (una ogni 15 partecipanti).


Il FORM che potremmo disegnare è il seguente: Frmviaggio

















Di conseguenza, occorrerà stilare una tabella di descrizione degli oggetti, del tipo:


NOME OGGETTO

TIPO

DESCRIZIONE

VARIABILE

METODO

EVENTO

frmviaggio

form

maschera


load

Iniz()

lbltitolo

etichetta

Titolo del Form




lbldenome

etichetta

Etichetta denominazione




txtdenom

Casella testo

Inserisce denominazione

strdenom









cmdcalcola

pulsante



click

Calcola()


A questo punto si compilerà la tabella delle variabili di memoria necessarie per l'elaborazione:


NOME

DESCRIZIONE

TIPO

ctotale

Totale importo

currency








Infine, si descriveranno i singoli metodi, in pseudocodicodifica o diagramma a blocchi:


iniz()


txtdenominazione =""

txtindirizzo = ""



fineiniz

Calcola

......

......

finecalcola

Completata la documentazione si potrà passare alla realizzazione di ciascun Form, con la relativa codifica.






Appendice 2: La progettazione dell'ipermedia.

Di Carmela Ciaravola e Maria Di Lillo


1. Multimedialità e ipertesti  




La multimedialità


La comunicazione delle dedellelle informazioni presuppone l'uso di uno strumento, un "media", cioè, che può essere la voce, un suono, un testo scritto, una foto, un filmato. Quando più media vengono usati contemporaneamente allo scopo di un risultato più immediato e più efficace si parla di comunicazione multimediale. Ad esempio, la radio è un mezzo di comunicazione che usa solo suoni, la televisione, invece, è multimediale, perché usa suoni, immagini fisse, filmati, scritte. Noi stessi siamo multimediali, perché comunichiamo non solo con la voce, ma anche con i gesti, con l'espressione del viso o addirittura con un profumo.

Anche un computer può essere multimediale, cioè può comunicare con l'esterno utilizzando più media. Certamente un tale computer deve disporre di opportune periferiche, aggiuntive a quelle classiche che sono la tastiera, il video, il disco, la stampante. Vediamo quali sono queste periferiche:

la scheda audio: perché un suono sia registrato da un computer, questo deve essere tradotto in una sequenza di bit. La scheda audio effettua questa trasformazione e quella inversa, necessaria perché noi possiamo udire il suono precedentemente registrato;

lo scanner: è un dispositivo che consente di catturare immagini e pagine scritte, trasformandole in sequenze di bit, così da poterle registrare in una memoria di massa;

la scheda video: consente di acquisire filmati registrati con una normale telecamera;

lettore di cd-rom: la maggior parte dei software multimediali è registrata su cd-rom, perché l'occupazione di memoria di una foto, o di un filmato, o di un suono è molto più elevata di quella di un testo scritto;

il masterizzatore: consente di copiare il contenuto dell'hard disk su cd-rom;

gli altoparlanti: consentono di sentire i suoni.

Naturalmente occorrerà disporre anche di software specialistici per il trattamento delle informazioni multimediali. Ad esempio, dopo aver acquisito con lo scanner l'intera pagina di un libro, potrei voler eliminare le parti inutili, modificare la grandezza, l'orientamento, il colore e per fare questo mi occorre un programma specializzato. Se voglio utilizzare le informazioni multimediali acquisite dovrò disporre di applicativi in grado di incorporare vari tipi di oggetti, come foto, film e suoni. Oramai la multimedialità è così diffusa che non ha quasi più senso acquistare un computer non multimediale, che non consentirebbe, ad esempio, la fruizione di tante enciclopedie oggi in commercio. Windows 95 e Office sono stati realizzati nell'ottica della multimedialità, così in un documento scritto in Word posso inserire un disegno o una foto, in una presentazione PowerPoint posso inserire foto, film, musiche, realizzando prodotti che raggiungono più efficacemente lo scopo comunicativo, oltre ad avere un aspetto decisamente più gradevole.



Gli ipertesti.


Un ipertesto è un testo che dà la possibilità di una lettura non solo sequenziale, una riga dopo l'altra, una pagina dopo l'altra, ma consente al lettore di seguire un percorso logico, dettato dalle sue esigenze di lettura. Naturalmente i percorsi possibili devono essere stati previsti in fase di costruzione dell'ipertesto, attraverso opportuni collegamenti o link. In particolare, una parola si può prestare, per il suo valore semantico, o per associazione di idee, ad essere il punto di collegamento con un'altra parte del testo. Facciamo un esempio. Supponiamo di scrivere un testo su Milano:

"Milano, città della Lombardia, situata nella pianura padana, fra i corsi dei fiumi Olona e Lambro".

Le parole sottolineate si prestano per un collegamento con un'altra parte del testo, dove ci sarà una spiegazione più dettagliata, che sarebbe inopportuno inserire direttamente nel contesto. Queste parole si dicono "calde" e sono normalmente evidenziate nel testo con una sottolineatura o con un diverso colore, così che il lettore possa accorgersi che c'è un link e decidere se continuare la lettura sequenzialmente o "saltare" ad un'altra pagina, clickando sulla parola.

Il concetto di ipertesto risale al 1945, quando lo scienziato americano Vannevar Bush pubblicò un articolo intitolato "Come potremmo pensare", in cui spiegava l'organizzazione della conoscenza in modo non sequenziale. In seguito venne coniato il termine "ipertesto", per indicare questo tipo di documenti. È più recente, invece, l'introduzione dell'ipertestualità nell'uso del computer.



Gli ipermedia.


Un ipermedia è un ipertesto multimediale. Tutte le enciclopedie in vendita, registrate su cd-rom, sono ipertesti multimediali, che consentono al lettore di realizzare percorsi di lettura autonomi in base allo scopo della ricerca.

Gli elementi costitutivi di un ipermedia si dicono oggetti: una pagina, il suo sfondo, una foto sulla pagina, un testo scritto, una parola calda sono oggetti, di tipo diverso, con differenti funzioni. Ogni oggetto ha delle proprietà che lo caratterizzano, diverse per i diversi tipi di oggetto: un disegno ha un colore di fondo e uno di bordo, un testo ha un colore, un tipo e una grandezza di carattere, una foto ha delle dimensioni, e così via. Ad un oggetto può essere associato anche un procedimento, detto metodo, cioè una sequenza ordinata di istruzioni, che saranno eseguite quando si compie un'azione, cioè accade un evento. Eventi sono ad esempio l'avvio di un'applicazione, l'entrata in una pagina, il click del mouse. Tali eventi vengono tradotti in messaggi inviati all'oggetto, determinando l'esecuzione del metodo corrispondente. Ad uno stesso oggetto possono essere associati più metodi, attivati da diversi eventi. Quando ad un oggetto è associato un metodo attivato dal click del mouse l'oggetto si dice pulsante. Le parole calde sono particolari tipi di pulsanti, ma anche una foto o un disegno possono essere pulsanti.


2.Gli elementi di un ipermedia.




La struttura.


La struttura di un ipertesto può essere:

gerarchica: quando i collegamenti procedono in un'unica direzione, diramandosi in modo sempre più dettagliato, come in un albero genealogico. La navigazione inizia sempre dal primo nodo, la radice, ed è fortemente limitata dalla rigidità della struttura. Ad esempio:



DI BASE

 







PROGRAMMI DI UTILITÀ

 

SISTEMA OPERATIVO

 


A griglia: quando i collegamenti sono sempre orizzontali o verticali. I nodi che si trovano sulla stessa riga o sulla stessa colonna generalmente contengono informazioni sullo stesso argomento. Questa struttura offre maggiori possibilità di navigazione, pur mantenendo una certa rigidità. Ad esempio:














ingresso


Reticolare: quando i collegamenti non hanno un ordine preciso. Questa struttura offre maggiori possibilità di navigazione, ma è anche più facile perdersi. È consigliabile utilizzarla con attenzione. Ad esempio:















MATERIE

 

ALUNNI

 

Il layout.


Il LAYOUT è la struttura delle pagine. Generalmente in uno stesso ipermedia non si trovano più di due o tre layout, ciascuno specifico di un certo tipo di pagina. Ad esempio si potrà decidere che la pagina generica sia divisa in due parti, che in quella di sinistra vi siano i testi e che in quella di destra vi siano foto e film, che gli strumenti di navigazione (i pulsanti di base pagina successiva, pagina precedente, fine, indice, help, MENU) siano posizionati in basso, mentre la pagina degli approfondimenti sia costituita da un'unica grande cornice all'interno della quale c'è una foto o un filmato o un testo, e così via. La scelta del LAYOUT è fondamentale: gli oggetti posizionati sullo schermo avranno pesi diversi in base alla loro posizione, dunque risulteranno più o meno evidenti a seconda del LAYOUT in cui sono inseriti, cosicché il lettore trovi subito le parti fondamentali. Un ipermedia ben strutturato risulta dunque generalmente più gradevole, di più facile consultazione e non stancante. Riportiamo qualche esempio di LAYOUT:







Il colore e gli sfondi.


Il colore è un altro elemento fondamentale dell'ipermedia. Tutti sanno che alcuni colori, come l'azzurro, sono rilassanti, altri, come il rosso, sono eccitanti. Inoltre un colore può richiamare alla mente un concetto per associazione di idee: ad esempio un marrone bruciato un po' sbiadito può far venire in mente qualcosa di antico. Infine l'accostamento dei colori può dare delle sensazioni particolari (es. bianco+grigio+azzurro=freddo). La scelta dei colori da utilizzare non è mai lasciata al caso, ma accuratamente ponderata.

Anche lo sfondo delle pagine è importante: deve adattarsi a tutte le pagine, qualunque cosa contengano, risultando gradevole ma non troppo evidente, perché distrarrebbe il lettore dal contenuto della pagina. Inoltre deve ben adattarsi agli strumenti di navigazione, che devono esservi incorporati, ma nello stesso tempo risaltare, perché il lettore possa individuarli facilmente. Uno sfondo non si sceglie per la sua bellezza, ma perché sta bene sotto gli oggetti in primo piano, per non rischiare disastrosi effetti d'insieme.


Il carattere


La scelta del carattere può condizionare il risultato finale, dunque sarà bene non lasciarlo al caso, ma decidere con molta cura il tipo, lo stile e la grandezza, tenendo presente che alcuni caratteri possono risultare di più facile lettura, altri possono colpire per la loro originalità, altri ancora possono prestarsi per richiamare automaticamente l'argomento che si sta trattando: la scelta deve tener conto di tutti i fattori. Possibilmente, si userà lo stesso carattere anche per la guida operativa, in modo da non disorientare il lettore che consulta l'ipermedia.


3. La progettazione dell'ipermedia.



3.1. Le fasi della progettazione.


Qualunque progetto può essere suddiviso in cinque fasi fondamentali :

studio di fattibilità;

studio del sistema;

macroanalisi;

microanalisi;

realizzazione.

Precisiamo qui che ciascuna fase dovrà essere adeguatamente documentata, che tutto il materiale prodotto sarà registrato in duplice copia, e che sarà tenuto continuamente aggiornato dai responsabili della documentazione.

Vedremo ora in dettaglio ciascuna fase.



3.2. Lo studio di fattibilità.


È la fase preliminare. Avvertita la necessità del progetto, si devono individuare con precisione:

gli obiettivi;

i contenuti di massima;

le risorse disponibili;

il destinatario del prodotto;

i tempi di realizzazione;

i costi;

le fasi in cui si articolerà il progetto;

il documento risultante costituirà la base del progetto, da cui si procederà per raffinamenti successivi, per ottenere specifiche sempre più dettagliate.



3.3. Lo studio del sistema.


Una volta definito l'ambito operativo occorre studiare in dettaglio il sistema a cui il progetto è riferito. Le modalità di studio del sistema possono essere molte. Ne suggeriamo una molto semplice. Per prima cosa si analizzeranno in dettaglio i contenuti, già specificati in linea di massima nello studio di fattibilità. Quindi si disegnerà l'architettura di sistema, una rappresentazione grafica, generalmente a forma di albero, in cui si evidenziano gli elementi del sistema e le relazioni gerarchiche che intercorrono fra essi. A questo punto si procederà con la raccolta del materiale necessario (testi, foto, film, musiche, registrazioni verbali, ecc.),con la sua rielaborazione e con la sua catalogazione per argomenti. Il materiale multimediale sarà ovviamente memorizzato, per renderlo disponibile per la fase di realizzazione.



3.4. La macroanalisi.


Occorrerà innanzi tutto decidere, se non lo si è già fatto nello studio di fattibilità, quale applicativo utilizzare per la realizzazione dell'ipermedia, scelta che condizionerà la progettazione, in quanto gli applicativi consentono prestazioni anche molto diverse fra loro. Si dovrà inoltre provvedere ad un attento esame dei contenuti dettagliati nella fase precedente, per eventualmente ridurli se i tempi indicati nello studio di fattibilità non consentono di trattarli tutti. Ricordiamo che la significatività dell'esperienza non dipende dalla vastità del prodotto ottenuto ma piuttosto dal corretto modo di operare nella realizzazione.

A questo punto si provvederà a stendere la mappa concettuale, un disegno che rappresenta i contenuti dell'ipermedia e tutti i collegamenti che si prevede di realizzare. Potrebbero non essere tutti i possibili collegamenti, ma solo quelli che si ritengono significativi, in base al probabile lettore a cui l'ipermedia è destinato. Per facilitare il compito si potrà partire dall'architettura, ampliandola con relazioni ulteriori.

Infine, prima di passare alla microanalisi, occorre decidere quale sarà la struttura dell'ipermedia, cioè:

di quanti libri sarà composto, quante e quali pagine per libro;

quali griglie saranno utilizzate;

quali colori;

quali caratteri;

quali sfondi;

quali strumenti di navigazione.



3.5. La microanalisi.


Sostanzialmente è la sceneggiatura delle pagine. Per prima cosa le si disegnerà accuratamente, quindi si produrrà un documento contenente, per ogni pagina, tutti gli oggetti, secondo lo schema:


nome oggetto

tipo

descrizione

metodi

eventi

Tempi











3.6. Realizzazione.


In questa fase le pagine sceneggiate saranno materialmente realizzate, utilizzando l'applicativo prescelto. Potrebbe accadere che la pagina subisca delle modifiche, per varie cause. In tal caso bisognerà modificare tutta la documentazione relativa, al fine di evitare incongruenze. Infine si provvederà a collegare le pagine ed i libri ed a mettere a punto il prodotto. L'ultimo passo è la scrittura della guida operativa per l'utente, nella quale si daranno tutte le indicazioni che si ritengono necessarie perché il prodotto possa essere fruibile nel miglior modo.



4. Un esempio.


Supponiamo di voler realizzare un ipermedia sulla storia egiziana, con una classe II.




Studio di fattibilità:


"LA CIVILTÀ EGIZIA"

Obiettivi:

riconoscere le componenti del sistema egizio;



Saper individuare le relazioni fra gli elementi del sistema;


Contenuti:

la civiltà del Nilo;

l'organizzazione statale;

la storia;

la religione.

Risorse:

docenti;

libro di testo;

testi della biblioteca;

laboratorio;

esperti esterni;


Destinatari:

- alunni di prima classe della scuola secondaria superiore;

Tempi:

secondo quadrimestre;

Costi:

£ ..... per l'esperto esterno;


Fasi di realizzazione:

FASE

RISORSE

DOCUMENTI PRODOTTI

TEMPI

Studio del sistema

studio di fattibilità

libro di testo;

testi della biblioteca;

esperto;

docente di lettere;

descrizione dettagliata dei contenuti;

architettura di sistema;

bibliografia;

gennaio (8 ore)

macroanalisi


fotocopie;

studio di fattibilità;

architettura di sistema;

materiale raccolto;

docente di T.I.C.;

mappa concettuale;

descrizione degli standard;

febbraio (8 ore)

microanalisi

mappa concettuale;

standard;

dettaglio contenuti;

bibliografia;

docenti;

sceneggiatura pagine;

descrizione oggetti;

marzo (8 ore)

realizzazione

tutti i documenti prodotti nelle fasi precedenti

ipermedia

Aprile-maggio (16 ore)



Studio del sistema:

Descrizione dettagliata dei contenuti:

la civiltà del Nilo:

posizione geografica;

caratteristiche climatiche;

periodi storici;

l'organizzazione statale:

il faraone;

la burocrazia;



Architettura di sistema:





geografia

 

 

Le piene

 

 

 

L'organizzazione  statale

 

La civiltà del Nilo

 


Ecc.


Bibliografia:


"La cultura della storia" di Cantarella-Guidorizzi, ed. Einaudi, pag. 48-65

( geografia e piene);

Atlante storico De Agostini, pag. 58 cartina (geografia): C:\IIC\FOTO\foto2;

" pag.59 cartina " :C:\IIC\FOTO\foto3;

Ecc.



Mappa concettuale:


CIVILTÀ DEL NILO GEOGRAFIA PIENE PERIODI

CIVILTÀ EGIZIA FARAONE BUROCRAZIA ORGANIZZAZIONE STATALE ECC.


Struttura:

1 libro composto dalle pagine:

p1 la civiltà egizia

p11    la civiltà del Nilo

p12    la civiltà del Nilo

p13    organizzazione statale

p111   geografia

p112   piene

p113   periodi storici

p114   periodi storici

ecc.

griglia







colori:

giallo;

marrone;

beige;

nero (testi);

rosso (parole calde);

carattere: Times New Roman 20-16-14

sfondi:

rif.bibl. 4 sfondo4;

Rif.bibl. 7 sfondo7;

C:\WINDOWS\.......;

Ecc.

strumenti di navigazione: pulsanti a forma di papiro (rif.bibl. .....)

AVANTI;

INDIETRO;

MENU;

FINE.



Microanalisi:

T11

  F11

 

B14

 

B13

 

B12

 

B11

 
p1    CIVILTÀ EGIZIA


p1 oggetti

nome oggetto

tipo

descrizione

metodi

eventi

Tempi

F11


B11

B12

B13

B14

T11

Immagine


Pulsante

"

"

"

testo

Foto (rif.bibl.7)


Icona id101

Icona id102



(rif.bibl. 12)

/


va a pag. seg.

Va a pag. prec.




/


click

click



1 sec. (entra da sinistra)

0

0

0

0

3 sec. (entra da destra)


(si ripete per tutte le pagine)






Bibliografia.


Roberto Raschetti : "Sistemi informativi e basi di dati" - Angelo Signorelli editore / Roma;

Roberto Melchiorri : "Documentazione Software" - Angelo Signorelli editore / Roma;

Piero Gallo - Flora Resta : "Dai media agli ipermedia" - Minerva italica;

F. Cesarini - F. Pippolini - G. Soda : "Elaboratori e loro applicazioni" - Edizioni Cremonese;

Giovanni Cupini - Nadia Ghesini : "Dalla programmazione imperativa alla programmazione a oggetti" - Zanichelli;

Wallace Wang : "Visual Basic" - Apogeo;

Fabio D'alessi - "Guida a multimedia Toolbook 4.0" - Tecniche nuove.











Privacy




Articolo informazione


Hits: 3438
Apprezzato: scheda appunto

Commentare questo articolo:

Non sei registrato
Devi essere registrato per commentare

ISCRIVITI



Copiare il codice

nella pagina web del tuo sito.


Copyright InfTub.com 2024