Regole generali

Gli elaborati devono essere svolti singolarmente. Dall'anno accademico corrente (2008/2009) non è più possibile presentare progetti sviluppati in gruppo.

I progetti Java sono i medesimi sia per gli studenti che seguono il corso dalla piattaforma online che per quelli in presenza. Non è possibile partecipare allo scritto senza aver sviluppato il progetto (ricordate che il corso contiene il sostantivo "Laboratorio" nel nome). Il progetto Java va consegnato al docente o al tutor una settimana (circa) prima della data dell'appello. Comunicazioni riguardanti le consegne e l'esame avverranno tramite pubblicazione di avvisi sulla pagina comunicazioni.htm.

Tracce elaborati Java

[Le tracce degli elaborati sono definitive, verranno eventualmente arricchite di particolari o precisazioni prima della fine del semestre.]

CONSIDERAZIONI GENERALI

Amministrazione di un condominio

Si vuole implementare un software per l'amministrazione di un condominio. Il condominio si compone di un certo numero di appartamenti, ciascuno dei quali è descritto dalle seguenti proprietà: il codice, la superficie, il numero di vani, il nome dell'inquilino. Ogni appartamento ha un unico proprietario, ma un proprietario può possedere più appartamenti. Di ogni proprietario interessano le seguenti informazioni: nome, indirizzo, telefono, saldo. Il saldo rappresenta la somma che il proprietario deve all'amministrazione condominale per servizi e lavori sostenuti o preventivati. Se il saldo è positivo, esso rappresenta un credito, mentre se negativo, il suo valore assoluto rappresenta un debito. Fra le spese si distinguono quelle speciali attribuibili ad un determinato appartamento per lavori o servizi ad esclusivo carico del suo proprietario. Di ogni spesa occorre conoscere il numero di identificazione, la voce (luce, ascensore, pulizia, ecc.), la data e l'importo. I proprietari effettuano di tanto in tanto dei pagamenti di cui occorre mantenere traccia. Ciascun pagamento è individuato da un numero d'ordine e deve riportare la data e l'importo. Ogni volta che si effettua una spesa (non speciale), essa viene addebitata a tutti i proprietari in misura proporzionale alla metratura degli appartamenti di loro proprietà. Ogni volta che un proprietario effettua un pagamento si incrementa il corrispondente saldo dello stesso importo. In ogni istante dovrà quindi valere il seguente vincolo di integrità:

somma_dei_pagamenti – somma_delle_spese = somma_dei_soldi

Possibili (ma non esclusive) funzionalità che il sistema di gestione dovrà fornire sono:

Sviluppare una interfaccia per l'applicazione. Una interfaccia di tipo console da riga di comando è sufficiente. Memorizzare le informazioni in files.

Gestione di un albergo

Si vuole implementare un software per la gestione delle prenotazioni delle camere di un albergo. Ogni camera è caratterizzata da un numero e da un certo insieme di possibili composizioni dei letti, ad esempio 1 (singola), 1+1 (doppia), 2 (matrimoniale), ecc. L’albergo accetta prenotazioni SOLO di gruppi di clienti; questi vengono eventualmente divisi in più stanze (pensate ad esempio alla trasferta di una squadra di calcio o ad un viaggio organizzato dove persone diverse vengono messe nella stessa stanza).

Ogni gruppo è caratterizzato da un nome, una data di arrivo, da una composizione per camere, dal valore dell'anticipo versato, ecc. All’atto dell’arrivo, il gruppo viene alloggiato nelle camere libere aventi la composizione richiesta. Il pagamento della pensione avviene per gruppi mentre quello degli extra (internet point, assistenza medica, consumazioni al bar o al ristorante, ecc..) avviene per stanza. A tale proposito è necessario registrare tutti gli extra di ogni stanza riportando data, il tipo e l’importo di ogni extra.

Prevedere dei servizi per: sapere quali camere libere esistono con una data composizione, accettare (respingere) la prenotazione di un gruppo, gestire l’arrivo e la partenza di un gruppo.

Battaglia navale “dinamica”

Il software deve consentire ad un giocatore di cimentarsi in una battaglia navale contro il calcolatore. Il gioco si svolge su di una scacchiera quadrata, di dimensioni variabili, che dovranno essere stabilite all’inizio della partita. La dimensione minima è di 8x8, quella massima 20x20. La dimensione di default è 10x10. Il quadrante del gioco è dunque una matrice quadrata, dove ciascuna casella è individuata dal numero di riga e di colonna.

Ogni giocatore dispone di un proprio quadrante. All’inizio della partita ciascun giocatore dispone sul proprio quadrante le proprie navi. Ogni giocatore dispone di una flotta composta da: una portaerei, una corazzata, due incrociatori, tre cacciatorpedinieri, e quattro sottomarini. I sottomarini occupano una sola casella; i cacciatorpedinieri occupano due caselle; gli incrociatori occupano tre caselle, le corazzate occupano quattro caselle, e le portaerei occupano cinque caselle. Ogni nave occupa un numero di caselle adiacenti pari alla dimensione della nave. Le caselle occupate devono trovarsi o sulla stessa riga o sulla stessa colonna. Una casella di un quadrante non può essere occupata da più navi.

Lo scopo del gioco è l’affondamento della flotta avversaria. Il gioco procede attraverso una sequenza di turni. Ad ogni turno i giocatori indicano una casella del quadrante avversario su cui sparare, e vengono informati di quale casella del proprio quadrante sia stata colpita. Il sistema indica se ciascun colpo è andato a vuoto o se ha centrato una nave. Quando la casella su cui si è sparato è occupata da una nave, questa viene danneggiata. Una nave affonda quando tutte le caselle da essa occupate sono state colpite.

Ad ogni turno, dopo che l’avversario ha sparato, ciascun giocatore può opzionalmente spostare un massimo di due tra le proprie navi non danneggiate in una nuova posizione libera. Una posizione è libera se le caselle che la formano non sono state ancora colpite dall’avversario e se soddisfa la condizione “ciascuna delle caselle della nuova posizione è adiacente (cioè hanno in comune un lato) a una qualunque casella occupata nella posizione precedente” (in sostanza potete spostare la neve di una casella in alto o in basso, oppure a destra o a sinistra). Se il giocatore sbaglia selezionando una posizione che non soddisfa i requisiti di posizione libera, il sistema deve essere in grado di guidare lo giocatore nella scelta della nuova posizione con dei suggerimenti.

Alla fine di un turno un giocatore risulta vincitore se ha ancora almeno una nave non affondata, mentre le navi dell’altro giocatore sono state tutte affondate. Se entrambi i giocatori finiscono di affondare le rispettive flotte nello stesso turno la partita termina pari.

L’interazione col sistema avviene attraverso la rappresentazione grafica dei quadranti. Le modalità precise di rappresentazione sono lasciate allo sviluppatore. L’interfaccia utente del giocatore “calcolatore” non è dotata di visualizzazione (anche se utile in fase di “debugging” del programma) e genera automaticamente i comandi. A questo proposito ipotizziamo che la generazione dei comandi avvenga in maniera casuale (disposizione casuale delle navi e determinazione casuale delle coordinate di sparo).

Prima di iniziare il progetto:

Per l'esame è suffiente sviluppare il software per giocare secondo le indicazioni date contro il calcolatore.

[FACOLTATIVO/AVANZATO:] In alternativa è possibile sviluppare un server di gioco e un client. Il server risponde su di una porta a vostra scelta in localhost (127.0.0.1). Il client riceve l'input utente e invia le mosse scelte al server da cui a sua volta attende le mosse. In un secondo momento il server potrebbe essere messo in rete e permesso il gioco a due utenti contemporaneamente nella modalità "utente contro utente". Se decidete di seguire questa strada, potete studiare questo nuovo esempio, GetRudimentale.java che vi può chiarire il funzionamento dei socket. Nel programma viene stabilita una connessione con un server web e viene salvata su file locale una pagina HTML prelevata dal server.

[FACOLTATIVO/AVANZATO:] L'interfaccia utente potrebbe essere sviluppata utilizzando classi swing.

JavaAir

Si vuole implementare un software per la gestione del programma fedeltà della compagnia aerea Java Air. Chi si iscrive al programma, ogni volta che vola con Java Air, accumula punti (miglia) che danno diritto a premi. Ad esempio, bisogna volare per almeno 25.000 miglia per avere diritto ad un volo gratuito in Europa; occorrono 65.000 miglia per un volo negli Stati Uniti; bastano 5.000 miglia per un buono acquisto in un negozio convenzionato.

Il sistema deve gestire i clienti della compagnia che partecipano al programma. I partecipanti sono organizzati in tre fasce di merito in funzione delle miglia volate durante un anno solare. Inizialmente tutti appartengono al primo livello; se si volano 35.000 miglia si passa al secondo livello; si accede al terzo livello con 100.000 miglia volate in un anno. I tre livelli danno diritto a facilitazioni e premi differenziati. Oltre ai clienti, il sistema deve gestire i tipi di premi (volo gratuito, soggiorno gratuito, buono sconto), il numero di miglia necessarie per ogni premio particolare (un volo gratuito a New York richiede più miglia di un volo per Roma) e lo storico dei clienti: quanti voli ha effettuato ogni cliente, quante miglia ha guadagnato, quali premi ha già riscosso e quante miglia gli restano da “spendere”.

Il sistema deve essere in grado di aggiornare la posizione di ogni cliente in funzione di ogni volo effettuato e di ogni premio richiesto. Occorre tenere in considerazione anche che le miglia accumulate scadono dopo 5 anni dal momento in cui sono state acquisite (cioè dalla data del volo).

Suggerimenti: L’applicazione non deve gestire l’intero piano di volo della compagnia aerea per sapere se la richiesta di un biglietto premio per una certa data può essere evasa. Semplicemente, se il cliente ha un numero sufficiente di miglia, viene erogato un voucher che poi il cliente utilizzerà nel momento della presentazione. L'elenco dei clienti, i relativi voli e l'elenco dei premi possono venire conservati in vari file.

[FACOLTATIVO/AVANZATO:] Memorizzare i premi, i voli e l'anagrafica clienti in un database (ad esempio MySQL).

Minesweeper (Campo Minato - Prato Fiorito - etc.)

Minesweeper (che ha assunto nel tempo vari nomi, tra cui "campo minato", "prato fiorito", etc.) è un gioco in cui il giocatore deve localizzare un certo numero di mine senza farne esplodere alcuna. Per alcune informazioni sul gioco si veda ad esempio Wikipedia. Il gioco è contenuto nell'installazione base di molti sistemi operativi; ad esempio Windows XP ne contiene una versione ("Campo Minato") in %SystemRoot%\System32\winmine.exe.

Scopo del progetto è quello di creare una applicazione di console che permetta di giocare a minesweeper. La dimensione del campo di gioco (una scacchiera) e del numero delle mine deve essere selezionabile dall'utente (anche tramite un file di configurazione). Il programma deve tenere traccia del tempo che l'utente impiega a trovare tutte le mine.

Vedere innanzitutto:

L'utente può indicare tramite le coordinate, quale casella vuole sondare o marcare come mina.

[FACOLTATIVO/AVANZATO:] L'interfaccia utente potrebbe essere sviluppata utilizzando classi swing.

Tracce elaborati PHP

Ai fini della valutazione verranno considerate la semplicità e la chiarezza del codice sviluppato per risolvere il problema. Eventuali integrazioni a quanto richiesto, quando concordate con il docente, saranno valutate positivamente.

Per l'esame è necessario accompagnare il progetto con una breve relazione che spieghi sinteticamente le scelte fatte e la struttura del codice. È importante essere sintetici (max 1 o 2 pagine).

Dall'anno accademico 2007/2008 è obbligatorio installare l'applicazione funzionante sul server php.dti.unimi.it avendo già predisposto un opportuno database di supporto. Questo da allo studente la possibilità di testare l'applicazione in un contesto di produzione (HTTPS è supportato) e inoltre garantisce allo studente che non sorgano problemi di installazione durante l'esame. È comunque necessario portare il sorgente PHP e SQL (per il database) su un supporto elettronico.

Software di gestione dell'orario delle lezioni

[Questo progetto è stato assegnato anche lo scorso anno, ma sto ancora cercando un progetto da inserire sul sito del dipartimento ...].

Sviluppare un'applicazione per la visualizzazione dell'orario delle lezioni (l'applicazione non deve predisporre l'orario!).

Predisporre innanzitutto un database opportuno che contenga la lista degli esami per ciascuno dei corsi di studio erogati presso il polo didattico di Crema. Le liste complete le trovate alla pagina: http://www.dti.unimi.it/pianostudi/elenco.php. Visto che l'applicazione si occupa dell'orario corrente dovete ovviamente considerate solo il caso di chi si è immatricolato dopo l'anno accademico 2003/2004. Il database deve anche riportare se un esame è obbligatorio o complementare (lo capite dalla presenza o meno do una crocetta nella pagina degli esami).

In secondo luogo il database deve contenere anche una tabella con la lista di tutti gli esami per i quali vengono erogate lezioni. La lista la trovate alla pagina: http://www.dti.unimi.it/pianostudi/esami.php. Notate che la colonna "2007" indica in quale semestre il corso prevede lezioni (se non c'è nulla vuol dire che il corso non prevede lezioni e potete trascurarlo). Per ogni corso il vostro database deve anche contenere il nome del docente, un acronimo del corso (una abbreviazione di poche lettere che potete inventare voi), il relativo orario (giorni della settimana e fascia oraria in cui si tengono le lezioni che può essere: 9–11, 11–13, 14–16 e 16-18. Suggerimento: costruite una ulteriore tabella che mettete in relazione con la prima in base al codice dell'esame.) e l'aula (prendete spunto dalle aule del polo di Crema compresi i laboratori).

Sviluppate quindi una pagina di amministrazione che permetta all'utente di modificare o inserire l'orario per un singolo esame. (La cosa migliore è forse che predisponiate una prima form con un menù a tendina che riporti tutti i corsi attivi e che permetta all'utente di selezionarne uno. A questo punto potete visualizzare lo schema di una settimana tipo da lunedì a venerdì con una checkbox per ogni fascia oraria) [Per chi vuole dilettarsi con AJAX, questa form è adatta].

Lato utente l'applicativo deve presentare una form php iniziale (si prenda spunto dall'immagine Form1) che richiede all'utente le seguenti informazioni:

Usando queste informazioni e il relativo data base l'applicativo deve generare una nuova form del tipo Form2 e Form5 con l'elenco dei corsi (e relativi acronimi) con a fianco una check box. Ci sono due casi:

  1. nel caso in cui sia stato richiesto il corso di studi "TUTTI" (cioè tutti gli esami a prescindere dal corso di studi) i checkbox devono essere per default non checked (si veda Form5).
  2. in tutti gli altri casi gli esami obbligatori devono essere checked ed i complementari no, in modo che ciascuno studente scelga gli esami che gli interessano. Alcuni complementari non hanno un anno di corso associato. Questi li dovete presentare quando lo studente seleziona un qualunque anno di corso (uno studente potrebbe frequentare un complementare al secondo ed un altro studente al terzo).

Quando l'utente ha scelto i corsi che gli interessano e richiede l'orario, l'applicativo deve generare l'orario (usando le informazioni sul data base). Ci sono due possibili formati per l'orario. Tali formati sono definiti dal campo visualizzazione della prima form.

Ci sono due casi:

  1. visualizzazione per giorno il risultato deve essere del tipo Form3 e Form6 (caso in cui ci sono piu' insegnamenti nello stesso slot giorno/ora)
  2. visualizzazione per corso il risultato deve essere del tipo Form4

Il migliore progetto presentato verrà effettivamente utilizzato sul sito del dipartimento ad uso degli studenti. Per questo motivo è importante rispettare le specifiche indicate per il software.

Software per la gestione di un gruppo ciclistico

Un locale gruppo di ciclisti amatori vi commissiona il nuovo sito internet. Il sito deve permettere ad ogni socio di crearsi un account con i propri dati anagrafici, di memorizzare i tempi ottenuti in ciascuna gara e pubblicare delle foto decidendo se sono pubbliche o meno. Gli account devono essere validati dall'amministratore che al momento del login, vede visualizzati i nuovi aspiranti membri del sito.

Per facilitare le trasferte, l'amministratore deve poter indicare a quali gare il gruppo intende partecipare in forma istituzionale. Al login gli utenti devono poter visualizzare tali gare e decidere se partecipare o meno. L'amministratore dal canto suo deve poter visualizzare quanti e quali sono gli iscritti alle varie gare.

Il sito deve prevedere quindi:

Le varie transazioni devono essere sufficientemente sicure

JavaAIR in PHP

Implementare il progetto JavaAIR, le cui specifiche sono riportate in questa pagina, in linguaggio PHP. L'utilizzo del database SQL è obbligatorio.

©2008 Roberto Sassi