Sagra di Cimpello Pro Loco Cimpello 1998

Perchè LinuxSagra?
In una piccola sagra di paese, come quella di Cimpello, capita spesso che la disorganizzazione prenda il sopravvento; in particolare è facile che le cucine si ``ingolfino'' e che quindi provochino un rallentamento generale.
Questo, oltre ad avere un effetto negativo diretto sulla clientela, che se aspetta troppo si scoccia, ha anche un effetto devastante sui volontari della Pro Loco, visto che solitamente provoca un innalzamento della tensione incredibile nelle ``stanze del potere'' (cucine e casse) e una serie incredibile di rimpalli di responsabilità che non servono a niente se non a complicare la faccenda.

Partendo da questa considerazione è chiaro che LinuxSagra non doeve solo fornire un DB per ``archiviare'' gli ordini ed evitare di fare i conti a mano sui blocchetti alla fine, ma anche un sistema completo che permetta una comunicazione cassa/cucina e soprattutto un sistema che, a fine giornata, di una statistica degli ordini e che quindi permetta un ``fine tuning'' alla giornata successiva.

Inoltre, è chiaro, LinuxSagra deve essere semplice, ovvero deve avere una interfaccia elementare e intuitiva ma soprattutto deve favorire il flusso di informazione (e di portate, e di clienti ;) e non intralciarlo.

Come implementare LinuxSagra?
L'idea che mi è sembrata piú intelligente è stata quella di fare una implementazione basata su web di LinuxSagra.
In questa maniera si sposta la complessità totalmente sul server, si eliminano tutte le limitazioni sui numeri di client presenti (LinuxSagra funziona con un unico terminale o con Internet attaccata, basta che il server regga ;) e soprattutto si può ``attaccare'' al server qualsiasi tipo di computer, dal pentium con netscape al C64 e il suo programma di emulazione di terminale.

Chiaramente questa flessibilità si paga con una discreta complessità de server, ma per questo è venuto incontro, inaspettato, php, che per lavori di questo tipo è un manna.

Analisi dei Requisiti
L'analisi dei requisiti è stata abbozzata da me, e poi è stata discussa assieme a Gianni Rizzo, un componente della Pro Loco che piú degli altri si intende di queste cose e che è stato ``incaricato'' a curare questi aspetti.

Piú che una analisi di requisisti di un sistema infromatico o di un DBMS è una vera e propria AdR di un sistema informativo, visto che si è pensato a un sistema complesso che prevede l'interazione di piú soggetti, attraverso strumenti diversi (computer, carta, fili e mollette da biancheria, ...) e in un contesto ``critico'' come quello di una sagra, che richiede accorgimenti hardware non indifferenti.

Progetto Concettuale
Il progetto concettuale è stato realizzato attarverso una schema Entità/Relazioni; (E/R) alcune entità e relazioni erano ovvie conseguenze dell'analisi dei requisiti, altre sono state aggiunte per avere uno schema che rispettasse le regole di una buona progettazione concettuale.

Visto che la complessità del sistema non lo giustificava, lo schema non è diviso in settori, ma è composto da un settore unico; la divisione in settori (cassa, cameriere, cucina) sarebbe stata una forzatura.

Progetto Logico
È stato utilizzato ovviamente il modello relazionale, utilizzando un certo numero di relazioni; anche qui alcune ovviamente ricavate dal progetto concettuale, altre che richiedevano un po' più di riflessione.

Progetto Fisico
Alcune note sulla implementazione e sulle query piú usate.