Laboratorio Specialistico 1
a.a. 2005-06
Progetto "E-shopping cart"
Il testo di questa esercitazione è volutamente poco tecnico per simulare
l’interazione con un committente, che non è interessato ai dettagli tecnici, ma
solo al risultato finale; quindi non definisce interamente un’unica
applicazione e viene pertanto lasciata una certa libertà nel proporre una
soluzione. La maggiore o minore ricchezza dell’applicazione proposta, la
quantità di aiuto richiesto, o errori corretti da un
docente, durante lo sviluppo contribuiranno al giudizio finale.
Si supponga di voler realizzare uno strumento per un ipermercato di prodotti alimentari utilizzabile sia nella gestione del magazzino sia nella vendita dei prodotti al cliente, in modo da facilitare da una parte il rifornimento di prodotti, e dall’altra l’emissione dello scontrino ai clienti e il relativo pagamento.
Nell’ipermercato è presente un magazzino in cui avviene lo stoccaggio dei prodotti, e tanti reparti di vendita. Per ogni tipologia di prodotto si vuole tener traccia di nome, prezzo di vendita, categoria merceologica, dimensione del lotto di acquisto, soglia minima che deve essere presente nell’ipermercato, soglia di acquisto a partire dalla quale occorre inviare un ordine di acquisto, fornitore a cui inviare l’ordine. Ogni fornitore è caratterizzato dal nome, partita IVA, indirizzo, telefono, e indirizzo di posta elettronica. Per ogni prodotto si vuole tener traccia della quantità presente in magazzino e nei reparti (lo stesso prodotto può essere presente in più reparti). Per ogni reparto, si vuole sapere la quantità minima di ogni tipologia di prodotto che deve essere sempre presente ed il responsabile.
Il personale dell’Ipermercato viene classificato in direttore, capi reparto e magazzinieri, tra i quali ve ne e’ uno sempre presente in servizio. Per ogni membro del personale si vuole mantenere il nome, cognome, indirizzo di posta elettronica, giorno di festa e orari giornalieri di servizio.
Per quanto riguarda la gestione del magazzino si vuole avere una gestione automatizzata del rifornimento dei prodotti. Ogni volta che la quantità di un prodotto va al di sotto della soglia di acquisto, occorre avvisare il magazziniere in servizio (tramite una notifica o una email: questa scelta e’ lasciata ad ogni gruppo e deve essere consistente nel progetto) di autorizzare l’invio di un messaggio di posta elettronica come ordine al fornitore di quella tipologia di prodotto per una quantità pari al lotto di acquisto. Se la quantità di un prodotto va al di sotto della soglia minima, occorre inviare un avviso di urgenza al magazziniere a cui era stato inviato in precedenza l’avviso più una notifica al direttore. Se la quantità di prodotto nel reparto va al di sotto della quantità minima occorre avvisare il corrispondente capo reparto di inviare un messaggio di posta elettronica con indicazione del prodotto che manca nel suo reparto al magazziniere in servizio.
Per quanto riguarda il supporto al cliente nell’acquisto, si vuole prevedere la possibilità di dotare ogni cliente con un palmare in cui annotare i prodotti inseriti nel proprio carrello. Dopodiché una volta raggiunta la cassa ed effettuato il pagamento, il carrello viene aggiornato come la disponibilità dei prodotti nell’ipermercato. Si vuole tener traccia degli scontrini emessi dall’ipermercato per eventuali analisi delle vendite. Ogni scontrino è caratterizzato da un numero progressivo (che lo identifica) e dalla lista di prodotti che sono stati acquistati.
MS .Net , con Visual Studio e C# , SQL Server
Accessibile dai laboratori DISI: SW2.
Ciascun gruppo può indicare l’orario preferito di utilizzo per prenotare una macchina nel laboratorio, ma non è richiesto che lo sviluppo dell’applicazione avvenga tutto nel laboratorio del DISI. È permesso lavorare a casa, fermo restando che l’applicazione consegnata deve funzionare nel nostro laboratorio e che nessuno, in particolare i tecnici, deve essere coinvolto nell’installazione e/o funzionamento su macchine private del sistema e/o applicativi necessari allo svolgimento del progetto.
Per monitorare l’andamento del lavoro dei vari gruppi, in modo da evitare dispersioni, verranno fissate delle milestone il cui rispetto verrà valutato in fase di correzione finale.
Per evitare inutili rigidità, ciascun gruppo fisserà le proprie, con i seguenti vincoli:
Ciascuna fase di lavoro verrà
seguita in particolare da un docente; si raccomanda a ciascun gruppo di
presentarsi un congruo numero di volte al docente interessato in ciascuna fase
(in orario di spiegazioni o prendendo appuntamento) in modo da permettere di
verificare la sensatezza del prodotto durante lo svolgimento, finché c’è tempo
per modificarlo, invece che in fase di valutazione finale. Nell’anno passato questa fase e’ stata sottovalutata dagli studenti!
La tabella dei docenti coinvolti nella supervisione delle varie parti è riportata al termine del documento.
Per la documentazione fare riferimento alle lezioni di scrittura tecnica (obbligatorio!)
Non verranno svolte ore di lezione in aula dopo il 15/10/05 ma e’ possibile che si organizzi un incontro al mese con chi potrà essere presente per rispondere a dubbi, analizzare insieme possibili alternative alle soluzioni eccetera.
MOODLE
Può essere utile
utilizzare il portale Moodle per
Ø
Scambio di informazioni tra gruppi
Ø
Invio di
news da parte dei docenti (si considereranno note a tutti dopo che sono state
postate)
In generale i
docenti non useranno Moodle per rispondere a
richieste degli studenti, in particolare sulle questioni tecniche collegate al progetto: il portale NON e’ uno strumento
sostitutivo degli incontri.
Si richiede di suddividere il monte ore previsto per l’esame (150 ore) per ciascun membro del gruppo fra le varie attività richieste per lo svolgimento. Si noti che per i gruppi formati da più di un individuo la somma totale delle ore risulterà maggiore di 150, perché gran parte delle attività non richiedono la partecipazione di tutti i membri del gruppo.
Documento da consegnare:
Si richiede di effettuare l’analisi dei requisiti dell’applicazione che si deve sviluppare. In questa fase occorre analizzare il problema proposto, effettuare una formalizzazione (ad alto livello) degli utenti che devono interagire con il prodotto software, dei moduli software che comporranno il sistema, delle interazioni che possono avvenire sia tra utenti e moduli che tra i diversi moduli.
Si suggerisce di estrapolare dalla descrizione del dominio e dai colloqui con i docenti i requisiti relativi alle funzionalità ragionevoli per una tale applicazione. Considerare anche quali sono i soggetti che possono utilizzare il sistema e quali operazioni sono autorizzati ad eseguire.
A titolo esemplificativo, si elencano alcune operazioni che non possono mancare.
- collegamento e autenticazione
- inserimento di prodotti in uno dei suoi reparti
- rimozione di prodotti
- ordini di prodotti
- Collegamento e autenticazione
- Inserimento/modifica/rimozione di prodotti nel carrello
- Pagamento degli acquisti effettuati
- catalogo generale dei prodotti presenti nell’ipermercato
- catalogo per tipologia di prodotto
- catalogo per disponibilità prodotti
- catalogo dei prodotti sotto scorta minima
- catalogo dei dipendenti dell’ipermercato (qualifiche, orari ecc.)
Documenti da consegnare: Occorre consegnare una descrizione a parole, corredata da diagrammi UML, per la specifica delle funzionalità dell’applicazione.
1.
Progettazione
concettuale della base di dati
Si richiede di sviluppare uno schema Entità-Relazione (o uno schema delle classi UML) per i requisiti sopra identificati. Lo schema dovrà essere il più chiaro possibile (quindi utilizzare al meglio gli strumenti messi a disposizione dal modello) e dovrà essere corredato da un insieme di vincoli di integrità, descritti in linguaggio naturale, non esprimibili nel modello.
2.
Progettazione
logica della base di dati
- Si richiede di sviluppare uno schema relazionale equivalente allo schema Entità-Relazione progettato come descritto al punto 1. corredato dell’informazioni sulle chiavi principali e chiavi esterne.
3. Progettazione logica operazioni e vincoli di integrità.
Si richiede di progettare le operazioni SQL necessarie all’applicazione, sotto l’ipotesi di utilizzare Microsoft SQL Server, utilizzando quando possibile procedure e funzioni. Si richiede inoltre di progettare tutti i vincoli di integrità (identificati nella fase di progettazione logica e che non possono essere rappresentati in SQL Server) come procedure.
Il codice SQL utilizzato durante lo sviluppo delle applicazioni dovrà necessariamente essere stato progettato in questa fase.
4.
Sviluppo
Si richiede di sviluppare la base di dati progettata (tabelle e procedure) utilizzando Microsoft SQL Server.
Documento da consegnare: Occorre consegnare il modello concettuale sviluppato, il modello relazionale, i vincoli di integrità espressi in linguaggio naturale con il codice SQL utilizzato per la loro verifica. Le interrogazioni in SQL sviluppate.
Documento da consegnare: descrizione concisa dell’architettura del sistema complessivo, indicando da quali applicazioni è composto(eg, client(s), server..) e dell’architettura interna di ciascuna di esse precisando quali componenti vengono usate, quali ne sono le interfacce ecc.
Potete definire diverse fasi intermedie (non più di cinque!) o consegnare tutto assieme, massima libertà sul numero di demo oltre che sulle date che fissate (es. demo amministratore, demo magazziniere, demo utente…)
Il progetto sarà concluso all’atto della consegna complessiva degli applicativi realizzati, completi di
- piani di test individuati come significativi (e sperabilmente superati dall’applicazione consegnata),
- diario dei partecipanti indicante quante ore sono state dedicate (e quando) a ciascuna attività. Questo documento, di cui viene fornito uno schema, sarà utile soprattutto per la pianificazione dei laboratori prossimi venturi.
Si prega di inviare una email al docente per avvisare quando avete bisogno di incontrarli.
|
|
Dodero |
Mesiti |
|
|
Mer. 14-16 o appuntamento |
Su appuntamento |
|
A |
X |
|
|
B |
X |
X |
|
C |
|
X |
|
D |
X |
|
|
E |
X |
|
|
F |
X |
|
Gruppo
Cognome |
Nome |
Login |
Email |
|
|
|
|
|
|
|
|
|
|
|
Milestones |
Consegna entro il |
|
Piano di lavoro |
|
|
Analisi dei requisiti |
|
|
Base di dati |
|
|
Definizione dell’architettura dell’applicazione e delle componenti necessarie |
|
|
Verifiche intermedie di funzionamento (demo) |
|
|
|
|
|
|
|
|
Consegna finale |
|