Completato

Note

Errore

Session expiration Your session is going to expireClick here to extend

Budget:

Piccolo progetto <800

Pubblicato il

08/07/13 21.14

Cliente

MP***

Questo progetto è scaduto

Pubblica un progetto simile e ricevi velocemente offerte non vincolanti.

Pubblica ora il tuo progetto simile

Descrizione

PROGRAMMAZIONE DISTRIBUITA (mod. A) Tesina 2012/2013 

Descrizione generale

Interfaccia Storage

Protocollo applicativo

Client

Server

Altre Specifiche

 

Package

Consegna

 

Descrizione generale

L’obbiettivo è quello di creare un server che visualizza su una interfaccia grafica oggetti di cui conosce solo l’interfaccia. Il server riceve da un client sia gli oggetti sia i comandi da eseguire su di essi. L’interazione con il server è controllata da un client che ha una interfaccia grafica attraverso la quale riceve i comandi da un operatore.

 

In altre parole, il codice del server conosce solo l’interfaccia degli oggetti che riceverà dai client. A tempo di esecuzione, i .class corrispondenti saranno resi disponibili al server sul proprio classpath (vedi ultima sezione della tesina).

 

Ogni client deve essere in grado di interagire con più server simultaneamente e un server deve essere in grado di ricevere comandi da più client simultaneamente.

 

Ogni studente deve fornire una classe server, una classe client, una implementazione per ogni interfaccia definita in questo documento.

 

I componenti sviluppati da uno studente devono essere interoperabili con i componenti sviluppati da altri studenti e tale requisito sarà verificato in sede di esame “accoppiando” gli studenti casualmente.

 

A tale scopo è assolutamente necessario attenersi strettamente alle specifiche di questo documento. Chi interpreta fantasiosamente le specifiche (ad esempio aggiungendo metodi alle interfacce, modificando parametri delle interfacce etc) provocherà un fallimento del test di interoperabilità, nel qual caso gli studenti dovranno farmi capire quale sia il problema e chi sia il responsabile.

Interfaccia Storage

Un oggetto Storage mantiene una sequenza di String e una sequenza di ImageIcon, inizialmente vuote. Le due sequenze hanno la stessa lunghezza e questa lunghezza è costante. L’oggetto ha metodi per inserire String nella sequenza e per inserire ImageIcon nella sequenza. Quando una sequenza è piena, una scrittura elimina dalla sequenza l’oggetto (String o ImageIcon) che era presente nella sequenza da più tempo.

 

Ogni Storage ha un nome. Il nome è una String, è definito quando l’oggetto è creato e non può essere modificato. Ogni Storage ha una size che rappresenta la lunghezza delle sequenze che contiene. Questo è un intero definito quando l’oggetto è creato e non può essere modificato.

 

Un Storage può essere congelato. Ciò significa che ogni successiva operazione di scrittura sul Storage lascia l’oggetto immutato. Un Storage congelato può essere distrutto e trasferito su file.

Protocollo applicativo

Il protocollo applicativo è request-response senza pipelining. Ogni connessione TCP trasporta una sola coppia request-response. La connessione è aperta e chiusa dal client.

 

Una richiesta può essere:

un oggetto Storage;

un oggetto MessagesToBeShown; l’oggetto specifica un Storage ed una lista di stringhe da scriverci, nell’ordine indicato (il primo elemento della List è il primo che deve essere scritto nel Storage).

un oggetto ImagesToBeShown: analogo al precedente, con riferimento ad immagini;

un oggetto Freeze; l’oggetto specifica un Storage da congelare.

un oggetto Destroy; l’oggetto specifica un Storage da distruggere.

una String dal valore “give me the Storage names”;

 

Storage, MessagesToBeShown, ImagesToBeShown, Freeze, Destroy sono interfacce definite in un jar associato a questo documento.

 

La risposta alle request 1-5 è un oggetto di interfaccia Outcome (anch’essa definita nel jar). La risposta alla request 6 è una List<String> contenente i nomi degli oggetti Storage esistenti sul server.

 

Un Outcome contiene un intero ed un Storage. Il primo elemento ha un valore che può essere una delle costanti seguenti:

Outcome.NAMEALREADYUSED quando si invia un Storage il cui nome è identico al nome di un Storage già esistente sul server.

Outcome.NAMENOTFOUND quando si tenta di modificare un Storage il cui nome non esiste sul server.

Outcome.NOTFROZEN quando si tenta di distruggere un Storage non congelato.

Outcome.FROZEN quando si tenta di scrivere su un Storage congelato o di congelare uno Storage già congelato.

Outcome.BADREQUEST quando si invia una request che non implementa nessuna delle interfacce permesse (1-5) oppure è una String il cui valore non è quello permesso (6).

Outcome.OK quando la request è stata eseguita correttamente.

Il secondo elemento è sempre null, ad eccezione della risposta alla richiesta Destroy; in questo caso contiene il Storage che è stato distrutto.

Client

Il Client ha un’interfaccia grafica attraverso la quale riceve i comandi da un operatore. In aggiunta ai comandi previsti dal protocollo applicativo, deve essere possibile:

creare un Storage vuoto di cui l’operatore specifica il nome;

salvare su file il Storage ricevuto come risposta della request destroy;

inviare al server un Storage precedentemente salvato su file.

inviare al server oggetti di almeno 3 classi diverse, serializzabili, che non implementano nessuna request permessa dal protocollo.

Il punto 1 è effettuato con riferimento all’implementazione di Storage realizzata dallo studente che ha implementato il client. I punti 2 e 3 con riferimento ad implementazioni di Storage realizzate anche da altri studenti. Il punto 4 può utilizzare classi della API standard.

 

Il modo con il quale l’operatore seleziona i comandi, sceglie il nome del Storage su cui operare, sceglie il server a cui inviare il comando e così via, non è specificato ad eccezione di quanto segue:

L’operatore deve potere scegliere le immagini da una lista di 10 immagini predefinite;

L’operatore deve potere scegliere i messaggi da una lista di 10 messaggi predefiniti e può inserire nuovi messaggi a proprio piacimento (senza modificare la lista di messaggi predefiniti).

 

Ogni Client deve potersi collegare con più Server simultaneamente, fino a un massimo di 5. Il Server con il quale collegarsi viene specificato dall’operatore inserendone indirizzo IP e port number nella GUI.

 

Il Client deve descrivere chiaramente nella GUI l’esito di ogni richiesta inviata. In particolare, deve mostrare il nome (fully qualified) della classe che implementa ogni risposta ricevuta.

Server

Ogni Server deve visualizzare gli oggetti Storage che ha ricevuto e non sono stati distrutti, fino ad un massimo di 6. Le modalità di visualizzazione non sono specificate, ad eccezione di quanto segue:

la visualizzazione deve essere di carattere grafico (JFrame);

ogni Storage deve essere chiaramente separato dagli altri Storage;

gli Storage congelati devono essere chiaramente evidenziati;

per ogni Storage devono essere mostrati gli elementi delle sequenze che contiene

Altre specifiche

Deve essere possibile avere simultaneamente in esecuzione sullo stesso calcolatore:

 

una o più istanze della classe Server, sviluppate anche da studenti diversi;

una o più istanze della classe Client, sviluppate anche da studenti diversi;

 

Ogni eventuale configurazione necessaria deve essere specificata attraverso opportuni oggetti Property. Questi oggetti possono essere specificati a linea di comando. Gli unici parametri ammessi a linea di comando sono quelli per specificare le eventuali Property necessarie.

 

Le uniche librerie ammesse sono le API della SDK ed eventualmente il codice generato dalla IDE per la parte grafica della console.

 

Le interfacce descritte in questo documento fanno parte di uno stesso package progdistrib.pkg2012 reso disponibile sul sito del corso e che deve essere utilizzato da ogni studente.

Esame Package

La tesina deve essere organizzata sotto forma di tre package.

 

corso2012.cognomestudente.commons deve esportare solo:

le classi che implementano le interfacce qui descritte.

corso2012.cognomestudente.server deve esportare solo:

il main del server

corso2012.cognomestudente.client deve esportare solo:

il main del client

Consegna

 

La tesina deve essere presentata sotto forma di un unico file .zip di nome corso2012.cognomestudente. Il file deve contenere:

Progetto Netbeans (o di altra IDE) per i 3 package sopra descritti. Il progetto deve contenere la documentazione generata via javadoc per le sole classi esportate dai package.

documento leggimi.pdf contenente:

intestazione con nome e cognome dello studente, anno accademico, corso di laurea:

principali problemi incontrati durante la realizzazione del progetto;

l’utilizzo del client e del server non deve essere descritto in questo documento ma deve essere descritto nei javadoc corrispondeti.

 

Il documento leggimi.pdf potrà essere reso pubblico dal docente su web. Chi non desidera vedere il proprio nome e cognome sul documento esposto su web, deve omettere queste informazioni dall’intestazione. Le sezioni del documento devono essere chiaramente separate da paragrafi di tipo “Titolo” o “Header” (non è accettabile un documento con paragrafi tutti dello stesso tipo Normal e separazione tra sezioni indicata solo tramite formattazione).