L'utilizzo dei modelli formali nel WWW

 

L'analisi formale dei requisiti di un sistema ipermediale può condurre a una struttura di progettazione estremamente solida, facile da modificare e internamente coerente. Purtroppo, per essere veramente efficienti queste metodologie devono prevedere un dominio dell'applicazione ben strutturato e documentato, mentre abbiamo visto che buona parte dei sistemi WWW da noi analizzati vengono generati per accumulazione successiva di materiale di diversa natura e modellazione.

Pure in [ISB95] si sottolinea come

lo sviluppo formale dei sistemi e le tecniche di gestione del progetto servono ad assicurare che il prodotto ipermediale raggiunga i suoi obiettivi e che sia completato in tempo e nei costi previsti

scopi che sono senz'altro più facili da identificare e raggiungere nel caso di prodotti stand-alone come possono essere CD-ROM, chioschi informativi o comunque prodotti ipermediali in cui il ciclo di vita è meglio definito e non soggetto a manutenzione continua, e spesso scarsamente controllata, come un sistema di tipo World-Wide Web.

Queste caratteristiche di ``prodotto'' possono però spesso presentarsi nel caso di un servizio WWW pensato (o ripensato) in maniera autonoma e con obiettivi precisi di visibilità: appartengono a questa categoria sia servizi di tipo commerciali, nello stile di ``vetrina'' di aziende o servizi (che infatti tradiscono la loro natura di prodotto concepito con tecniche proprie di un altro medium), sia veri e propri sistemi informativi di enti o istituzioni in cui lo sforzo di progettazione è stato pensato come momento di razionalizzazione del dominio dei dati (ad esempio [AD95]). In questi casi, un modello formale può essere applicato con efficacia, ed efficacemente mantenuto se per la manutenzione si adottano le stesse tecniche utilizzate nella progettazione.

Evidentemente, queste esperienze ricadono sotto il modello centralizzato, in quanto questo controllo è condizione importante affinché siano rispettate le metodologie formali scelte per la progettazione. Va da sé che la scelta di munirsi di un sistema formale di progettazione è un buon motivo per preferire un modello centralizzato e un sistema informativo monolitico.

Per quanto riguarda i modelli fortemente orientati all'accoppiamento con una base di dati (RMM, ma anche LINCKS [Sjö94] e DB [VNC+95]), gli stessi autori sottolineano come l'alta strutturazione del dominio sia una condizione necessaria per la piena messa in opera della metodologia, e in [Kes95] si parla anzi di compilazione HTML di ipertesti di grandi dimensioni e dalla struttura regolare. Pochi servizi di tipo WWW cadono integralmente (a meno di sforzi) in questa tipologia.

Un caso interessante e potenzialmente molto promettente è quello in cui una parte del sistema informativo risponda adeguatamente ai requisiti di strutturazione. Vedremo come in questo caso, all'interno di un modello cooperativo, è possibile gestire questa sezione in maniera confacente a una metodologia formale, per esempio utilizzando la RMM. Un esempio subito evidente è un sistema informativo universitario, dove a informazioni di varia natura (storia, presentazione, gruppi studenteschi, eccetera) si affiancano dati tratti da basi di dati quali ordinamenti o orari dei corsi.

Tra i casi studio del modello cooperativo vedremo appunto il servizio realizzato dalla coalizione dell'Ulivo (§ 8.2.3) in cui la sezione dei candidati è stata realizzata in maniera automatica a partire dalla base dati contenente informazioni già organizzate.