Sistemas Distribuídos

Licenciatura em Informática de Sistemas

Trabalho prático
2022

- Trabalho em grupo
- Enviar até 27 de Novembro 23:59 horas (Domingo à noite)
- Entregas com atraso serão penalizadas (10% por dia de atraso)

Leia com atenção as instruções que se seguem antes de resolver o teste e volte a ler
antes de enviar a sua resolução

A resolução do trabalho deve ser enviada para o Google Classroom cujo nome do
ficheiro deve ter o seguinte formato: SD-TP1 – nº 99999 – Fulano1.Fulano2.FulanoN
(onde 9999 é o número de grupo e Fulano1, Fulano2…FulanoN são apelidos dos alunos
integrantes do grupo).

A resolução deve ser enviada num ficheiro de texto.

Devem implementar e testar, devem enviar o projecto netbeans ou outro em um
ficheiro compactado; O ficheiro deve conter a vossa identificação (conforme a
regra acima apresentada)
Devem identificar o número de cada resposta.
Copiar para o ficheiro da resolução todo o conteúdo das classes que criarem;
Copiar o conteúdo da consola do cliente com o output da execução de cada uma das
opções pedidas.

Cotação do trabalho:

Trabalho sem callback e sem persistência de dados: 14 valores.

Implementação de persistência de dados usando ficheiros de objectos: 3 valores.
Implementação do callback: 3 valores.

1
 Enunciado

Queremos uma aplicação que permita gerir a partilha de recursos entre uma população.
Por exemplo, alguém disponibiliza um livro que poderá ser requisitado por outros e
devolvido após uso. Para isso queremos uma aplicação cliente/servidor em java RMI, em
que no processo servidor um objecto remoto disponibilizará as seguintes operações:

Op1 - Inserir recurso. O processo cliente fornece ao servidor os dados do recurso que
disponibiliza.

Op2 – Consultar recursos. O processo cliente fornece um valor do tipo String, o método
devolve todos os recursos que na sua descrição contêm essa String.

Op3 – Requisitar/Reservar um recurso. O cliente envia o identificador do recurso que

pretende, e envia também o endereço de um objeto para o qual o servidor poderá fazer
um callback. Se o recurso estiver disponível, o recurso fica assinalado no servidor como
passando a estar “requisitado”. Se o recurso já estiver atribuído a um cliente, passará ao
estado “reservado”. O cliente deve receber como resultado uma String, com o estado do
recurso. Quando o recurso for devolvido, o cliente que o reservou deve receber um
callback a avisar que o recurso já está disponível. Após o callback, o recurso passará para
o estado “requisitado”.

Op4 – Devolver um recurso. Um utilizador devolve um recurso que requisitou. O recurso

passa ao estado “disponível”.

Op5 – Listar recursos. O servidor envia ao cliente uma lista de todos os recursos
disponíveis.

- Um recurso será um objeto do tipo listado abaixo. Cada aluno deve considerar como
recurso o tipo cujo número corresponde ao último dígito do seu número de aluno. Isto é,
alunos cujos números de aluno terminem em 0 terão uma aplicação que gere a partilha de
Bicicletas. Alunos cujos números terminem em 1 terão uma aplicação que gere
Trotinetes, e assim por diante. Cada aplicação deverá definir uma classe com atributos
que descrevam as características do recurso que vai gerir. Por exemplo, a classe Bicicleta,
terá atributos como: se é de criança se é de adulto, número de mudanças, etc …

0 – Bicicletas;
1 – Trotinetes;
2 – Carros;
3 – Motociclos;
4 – Jogos de tabuleiro;
5 – Trajes académicos;
6 – Material de construção;
7 – Material de jardinagem;
2
8 – Equipamento de apoio a pessoas com incapacidade;
9 – Livros.