aluno: Jorge Augusto Melegati Gonçalves
ano/sem: 2008/2o.
data do laboratório (num. da semana) : 20/12/2008
Introdução
Neste laboratório, foram implementadas melhorias em um backend de um bolão virtual, utilizando um paradigma cliente-servidor, incluindo melhoria em decoradores, criação de um protocolo de comunicação, implementação da interpretação de requisições e criação de um servidor.
Desenvolvimento
Melhoria nos Decorators de ThreadSafety
Nesta etapa foram criadas as class MatchListThreadSafeDecorator que decora todos os elementos da MatchList com um MatchThreadSafeDecorator.
A implementação foi bem simples, visto os exemplos que já existiam.
Melhoria nos Decorators de Persistência
Analogamente, foi criado o MatchListPersistanceDecorator que possui uma peculiaridade:
ele deve ser utilizado conjuntamente com o ListPersistanceDecorator, porque é este o decorador que implementa as operações de save e load_list. Isso é garantido na MatchListBuilder quando se adiciona a persistência.
Criação de Builders
Os builders da MatchList e da UserList foram criados sem maiores problemas, seguindo as especificações.
Foram criadas as funções add_persistance, add_thread_safety and add_logging para as duas listas.
No caso da UserList foram utilizados os decoradores: ListPersistanceDecorator, etc.
Interpretação do protocolo de entrada e saída
Como esta atividade era para ser feita em dupla, utilizei praticamente o mesmo protocolo que a Lívia, entretanto, criamos diferentes formas de interpretar esse protocolo.
Na implementação, utilizou-se uma classe RequestReader responsável por toda a interpretação dos comandos, através de um método processa_requisicao. Este método é bem simples, consistindo basicamente de um case em que cada opção é uma das possíveis requests do protocolo, dentro destas são realizadas todas as tarefas inerentes àquela request.
Para mostrar a boa execução, criou-se um arquivo entrada.yml, com uma requisição de cada tipo do protocolo. Além disso, foi criado um arquivo create_lists para criar os arquivos com as listas de usuário e de jogos e populá-las. E este arquivo foi passado como parâmetro do main assim como um arquivo de saída saida.yml.
Conteúdo do arquivo entrada.yml.
INICIO
---
request:
operation: create_user
parameters:
username: jorge
password: comp10
FIM
INICIO
---
request:
operation: authenticate_user
parameters:
username: jorge
password: comp10
FIM
INICIO
---
request:
operation: get_current_matches
parameters:
FIM
INICIO
---
request:
operation: get_finalized_matches
parameters:
FIM
INICIO
---
request:
operation: get_match_info
parameters:
match_name: "Sao Paulo x Palmeiras"
FIM
INICIO
---
request:
operation: make_bet
parameters:
match_name: "Sao Paulo x Gremio"
score: "5 x 0"
FIM
INICIO
---
request:
operation: get_bets
parameters:
FIM
INICIO
---
request:
operation: close_connection
parameters:
FIM
E, no arquivo de saída, obtivemos a seguinte resposta:
INICIO
---
:response:
:status: success
:message: Usuario inserido
FIM
INICIO
---
:response:
:status: success
:message: Usuario e senha validos
FIM
INICIO
---
:response:
- :end_time: 24/12/2008 07:43
:name: Sao Paulo x Flamengo
:bet_count: 0 bets
- :end_time: 24/12/2008 07:43
:name: Palmeiras x Gremio
:bet_count: 0 bets
- :end_time: 26/12/2008 15:16
:name: Sao Paulo x Gremio
:bet_count: 0 bets
FIM
INICIO
---
:response:
- :end_time: 20/12/2008 23:10
:name: Sao Paulo x Palmeiras
:winners: no winners
:final_score: 3x0
:bet_count: 0 bets
:finalized: finalized
FIM
INICIO
---
:response:
:end_time: 20/12/2008 23:10
:name: Sao Paulo x Palmeiras
:winners: no winners
:final_score: 3x0
:bet_count: 0 bets
:finalized: finalized
FIM
INICIO
---
:response:
:status: success
:message: Aposta salva!
FIM
INICIO
---
:response:
:current_bets:
- :score_bet: 5x0
:match: &id001 !ruby/object:Match
name: Sao Paulo x Gremio
bets:
- !ruby/object:Bet
holders:
- !ruby/object:User
crypted_pass: e572208adea541350bf98378cbd10870d48eb785
salt: 0.8818795429693791
username: jorge
match: *id001
score: 5x0
end_time: 2008-12-26 15:16:49.162000 Z
:finalized_bets: []
:winning_bets: []
FIM
Uma segunda execução com a mesma entrada, mostra algo interessante que foi implementado. Como o usuário jorge já foi criado, ele não mais será criado, assim quando se quiser criá-lo novamente será lançada uma exceção que será pega na classe RequestReader e será colocada como resposta no arquivo saída.yml. Como mostrado abaixo:
INICIO
---
:response:
:status: failure
:message: Username taken!
FIM
Criação do Servidor Multithread
A criação do servidor multithread foi parte relativamente simples do laboratório mas, na qual, mais se pode ter novas experiências, uma vez que é mostrado como se cria aplicações em um servidor.
A seguinte tela mostra a execução de operações em duas telas do Telnet:
Execução dos testes
Foram modificadas algumas linhas do arquivo de testes para compatibilizá-las com a forma que os decorators foram criados, adicionando as chamadas ao load_list, pois estas tinham que ser chamadas a menos que se usasse o builder que tinha uma chamada a este método implicitamente.
A seguinte tela mostra a execução correta dos testes:
Conclusão
Os objetivos do laboratório foram alcançados com excessiva dificuldade, especialmente a parte da implementação da interpretação no qual as instruções não foram muito claras.
Ademais, pouco se pode absorver da linguagem Ruby, focando-se mais na busca de esclarecimento dos requisitos.
Como ponto positivo, observou-se as facilidades da programação em uma linguagem dinâmica e o primeiro contato com vários princípios básico de computação como multithread e programas que se comunicam via rede.
E isso foi bem simples devido à facilidade de implementação desses na linguagem Ruby.
