UFABC - MCTA025-13 - Sistemas Distribuídos Prática
Segundo Quadrimestre de 2018 - Turma NA1
Turma NA1
Professor: Emilio Francesquini
E-mail: e.francesquini@ufabc.edu.br
Alunos
Teremos no quadrimestre um total de 17 aulas teóricas sendo que 3 delas serão avaliações (P1, P2 e PSub). Conforme critério de avaliação, faltas acima de 25% (contando tanto prática como teoria), implicam reprovação com conceito O.
| RA | Grupo Proj. 1 | Grupo Proj. 2 |
|---|---|---|
| 11001814 | 2 | 10 |
| 11004613 | 4 | 4 |
| 11021314 | 9 | 2 |
| 11025214 | 6 | 10 |
| 11027513 | 3 | 0 |
| 11028613 | 1 | 8 |
| 11031115 | 13 | 7 |
| 11032414 | 0 | 0 |
| 11035011 | 4 | 4 |
| 11035014 | 1 | 8 |
| 11037213 | 0 | 0 |
| 11038215 | 13 | 7 |
| 11038216 | 0 | 0 |
| 11043111 | 5 | 3 |
| 11043313 | 0 | 0 |
| 11049914 | 8 | 0 |
| 11053015 | 8 | 0 |
| 11062715 | 3 | 9 |
| 11070111 | 0 | 0 |
| 11073415 | 12 | 11 |
| 11075613 | 11 | 6 |
| 11075614 | 11 | 6 |
| 11088512 | 0 | 0 |
| 11110012 | 3 | 9 |
| 11110915 | 12 | 11 |
| 11114710 | 7 | 0 |
| 11115013 | 4 | 4 |
| 21002513 | 6 | 10 |
| 21017613 | 0 | 0 |
| 21023314 | 7 | 5 |
| 21028815 | 10 | 1 |
| 21032114 | 9 | 2 |
| 21036413 | 5 | 0 |
| 21036615 | 11 | 6 |
| 21039614 | 0 | 5 |
| 21044612 | 7 | 5 |
| 21068112 | 2 | 0 |
| 11201722998 | 5 | 3 |
| 38 |
Projeto 1 - Java Remote Method Invocation (RMI)
| Grupo | Nota Original | Dias Atraso | Nota Final | Comentários |
|---|---|---|---|---|
| 1 | 9.0 | 0 | 9.0 | Relatório muito bem detalhado contendo casos de uso triviais e não triviais (por exemplo, "Servidor 04"). Descreve em detalhes como utilizar o projeto (tanto compilação quanto execução). Código bem documentado e estruturado. As ideias de que cada servidor possa criar repositórios interativamente, uso de exceções e o uso de UUID são muito boas e vão além do que foi pedido no enunciado. |
| 2 | 9.0 | 0 | 9.0 | Código bem escrito e estruturado (MVC/Inspiração Spring). Talvez até um pouco over-engineered. Documentação clara, contudo com muitos erros de português (cuidado!). Um dos únicos que tratou a saída dos servidores removendo-os do registry. A implementação de subpeças remotas é feita por cópia e não referência. |
| 3 | 7.0 | 0 | 7.0 | Documentação bem escrita, passando por vários trechos relevantes do código. No Servidor.java por que não usar um HashMap? A interface desenvolvida é bem confusa (apesar do que diz o relatório, ela não segue o que foi sugerido). Permite a inclusão de peças remotas. A interface contudo é simples demais (comandos inválidos são ignorados, não há um comando de ajuda, o nome do servidor que está conectado é impresso em momentos que parecem arbitrários, …). Implementa todas as funcionalidades pedidas indiretamente. Várias das funcionalidades pedidas aparecem apenas como efeitos colaterais dos comandos disponibilizados. A implementação de subpeças remotas é feita por cópia e não referência. |
| 4 | 6.5 | 0 | 6.5 | A interface Part.java sem nenhum método serve no final apenas como um flag nas outras classes. Não tem função mesmo porque toda a comunicação entre servidor e cliente é com troca de strings. Em nenhum momento são transferidos objetos mais estruturados. O relatório descreve as classes e arquivos mas não explica o uso ou como a compilação deve ser feita. O servidor cria sempre pelo menos um registry, mas depois conecta-se no primeiro dos registries que já existiam (se ele não for o primeiro), não há uma razão clara do porquê fazê-lo. A criação de peças é feita por cópia (dos atributos) e não por referência. |
| 5 | 10.0 | 0 | 10.0 | Relatório bem escrito, descreve o funcionamento com detalhes. Faltam informações apenas sobre a compilação. Código não comentado, porém simples e direto ao ponto. Tratamentos de erro muito bem feitos (inclusive para casos de perda de conexão com os sevidores). A implementação de subpeças remotas é feita por referência. |
| 6 | 8.0 | 0 | 8.0 | O texto e os exemplos apresentados no relatório são bem detalhados. Mostram o passo a passo do uso do cliente e também têm o cuidado de mostrar como o servidor e clientes devem ser executados. A criação de peças é feita por cópia e não por referência. A lista dos comportamentos pedida no enunciado é quase que completamente seguida. Faltam alguns pequenos detalhes como: listar o nome do repositorio atual e mostrar em qual repositório uma peça está localizada. |
| 7 | 4.5 | 4 | 2.3 | Documentação pouco detalhada, o que é realmente uma pena já que o código apresentado foi bem feito. A criação de múltiplos registries é esquisita, não fui capaz de compreender o que se desejava fazer. As operações fazem apenas parte do que foi pedido (não é mostrado o id de uma peça por exemplo). Também não fui capaz de criar uma peça com subcomponentes (e por consequencia criar uma peça com componentes remotos). |
| 8 | 0 | ∞ | 0.0 | Não entregue. |
| 9 | 5.0 | 1 | 4.0 | Relatório curtíssimo e extremamente superficial. Passagem de Parts por valor e não por referência. Não fui capaz de criar uma subpeça de outra peça e também não fui capaz de interoperar os servidores. A lista de operações está incompleta. |
| 10 | 5.5 | 0 | 5.5 | Relatório curto e superficial. Não oferece informações detalhadas sobre como compilar e executar. Arquivos fonte salvos em ISO-8859-1 causando erro de compilação: error: unmappable character for encoding UTF8. Tem um arquivo PartView.java (que não é usado por ninguém!) sobrando no diretório src que causa erro de compilação. Código sem qualquer tipo de comentário. NPE na descrição de uma peça que teve adição de sub-peças de outro repositório. Não usa exceções remotas e (cliente linha 77-78) e acaba fazendo 2 chamadas quando poderia ser feita apenas uma. |
| 11 | 4.0 | 0 | 4.0 | Relatório não descreve compilação ou execução. Apesar das explicações, não está claro porque se decidiu criar diversas classes Part quando apenas uma já seria suficiente. PartRepository com nomes fugindo ao padrão (iniciando com letra maiúscula). No PartRepositoryA por que não usar um HashMap? Boa ideia começar o servidor com uma coleção de peças inicial, contudo está no arquivo errado ProjetoSD.java. Cliente.java linhas 19-59: pra que isso? Servidor.java qual a razão de se criar um repositório composto se não é usado? O servidor não chega a executar (há um erro de cast logo na inicialização) e ainda que não houvesse todos os servidores se registram com o mesmo nome (sem usar rebind). Cliente não implementa todos as funcionalidades pedidas. |
| 12 | 4.5 | 0 | 4.5 | Documentação bem superficial. Não traz nenhuma informação sobre como o projeto deve ser executado ou compilado. Atenção para convenções de código, por exemplo: utilização de tabs e espaços nos mesmos arquivos para identação, uso de alguns métodos com nomes começando em maiúsculas e outros em minúscula, uso de acentos no nome de em alguns identificadores e não em outros, … Porque os comandos do gerenciador recebem o registry como parâmetro? A ideia de que o cliente é apenas um shell e todos os comandos são enviados para processamento no servidor é interessante. Contudo é preciso tomar cuidado com clientes simultâneos. addP talvez não tenha acontecido como esperado pois toda a interação com o usuário precisa ocorrer do lado do cliente não do lado do servidor. A interface Part não é usada em lugar algum. Arquivos fonte salvos em ISO-8859-1 causando erro de compilação: error: unmappable character for encoding UTF8. Arquivos vieram fora dos diretórios corretos considerando os seus pacotes. Usa um registry por servidor, dificultando a listagem de servidores. Lista de comandos obrigatórios incompleta. |
| 13 | 8.5 | 0 | 8.5 | Interessante a ideia de colocar um repositório Git e compartilhar com o professor. Isto ajuda na correção pois é possível ver os passos que seguiram. Sugestão para a próxima: o GitHub (assim como muitos de seus concorrentes) oferece contas com repositórios privados para estudantes. O relatório descreve os comandos que foram criados, porém é bem superficial na descrição da execução e compilação do projeto. A ideia de criar uma interface comando e suas diferentes implementações melhorou muito a legibilidade do código, contudo quase não há comentários no código. A escolha de usar um registry por servidor foge um pouco do tradicional, o que acaba forçando os usuários a usar IPs e portas e dificulta muito a listagem dos repositórios disponíveis por exemplo. Não é possível criar peças compostas (por cópia/referência) com subcomponentes de outro repositório. |
Projeto 2 - DHT
| Grupo | Nota Original | Atraso Grupo | Dias Atraso Projeto | Nota Final | Comentários |
|---|---|---|---|---|---|
| 1 | 0.0 | 1 | 4 | 0.0 | Entregue apenas um arquivo, sem relatório contendo um código genérico que apenas abre um socket no endereço e porta infomados pelo usuário. |
| 2 | 1 | ∞ | 0.0 | ||
| 3 | 1 | ∞ | 0.0 | ||
| 4 | 10.0 | 0 | 0 | 10 | Relatório muito bem escrito e detalhado. A GUI fornecida facilita muito a interação com o usuário e deixa mais claro o que cada nó da rede armazena. Implementou todos os milestones. |
| 5 | 8.0 | 0 | 0 | 8.0 | Relatório organizado, e bem escrito. Tive bastante dificuldade para utilizar a interface web disponibilizada. Ela travava frequentemente e não era estável. Nem sempre a busca por dados armazenados em outros nós funcionava, diversas vezes a mensagem parecia ficar girando em loop pelo anel até que um dos servidores parava de executar. As mensagens parecem ir no sentido inverso no anel. Implementa (com alguns erros) os milestones 1, 2 e 3. |
| 6 | 7.5 | 0 | 1 | 6.0 | Código pouco organizado, constantes hardcoded espalhadas pelo código. Há também o uso de diversas classes diferentes para cada uma das conexões (RecebeMensagemExt/Ant/Suc) complica desnecessariamente o design e a implementação do código. Não implementa a transferência de dados armazenados na entrada nem na saída dos nós da rede (mas implmenta store e retrieve parcialmente). O relatório poderia ter sido escrito de uma maneira mais clara e objetiva (por exemplo, não faz sentido dizer que usa try/catch). Duas cópias do mesmo código com organizações diferentes. Na classe RecebeMensagemAnt, ao receber uma mensagem storeMsg repassa ao sucessor uma Retrieve, por quê? O store não trata o caso da mensagem com IDs que dão a volta no anel. O código implementa (com alguns problemas) os milestones 1 e 2 e parte do milestone 3. |
| 7 | 6.0 | 0 | 0 | 6.0 | Relatório conciso e bem escrito. Conforme os próprios autores implementam o milestone 2 apenas. Código bem organizado, estilo MVC. Separação bem interessante entre as comunicações internas e externas (API do usuário). Não apresentaram uma aplicação que use a API nem implementaram store, retrieve e consequentemente transferência de dados entre os nós. O uso de REST é bem interessante e permitiu uma simplificação da conexão entre os nós da DHT. |
| 8 | 9.5 | 0 | 0 | 9.5 | Apesar de estar muito bem escrito, o relatório não obedeceu a limitação de 4 páginas especificada no enunciado. Código muito bem estruturado e de maneira muito inteligente se aproveitou da serialização do RMI para fazer a comunicação entre os nós da rede. Implementou todos os milestones previstos no enunciado. Há apenas um pequeno problema na hora de escrever o arquivo de nós caso o diretório não tenha sido criado, bastou criar o diretório para tudo funcionar. |
| 9 | 3.0 | 0 | 2 | 2.1 | Relatório sem informações sobre como compilar ou executar o projeto. A ideia de utilizar uma regex para parsear os comandos é interessante e facilita a implementação. Contudo as regex estão espalhadas pelo código o que dificulta a leitura. O aquivo App.java poderia ter sido quebrado em mais arquivos para facilitar a implementação. Não implementa os milestones 1 ou 3 e apenas implementa parcialmente o milestone 2. O não é calculado, é informado pelo usuário. |
| 10 | 7.0 | 0 | 0 | 7.0 | Os milestones 1 e 2 foram completados, contudo a transferência de conteúdo entre os nós e a busca não funcionam corretamente (cenário, cadastra um contato em um nó e busca este contato em outro). Assim, apenas parte do milestone 3 foi completado. O código está bem estruturado e a interface web para acessar a DHT também está bem feita. O relatório também está bem escrito apenas de ser confuso utilizar uma porta diferente para o servidor web e outra para as conexões da DHT. |
| 11 | 7.0 | 1 | 0 | 6.0 | O relatório descreve os métodos da implementação (até o ponto de descrever que o método x chama o método y), e não como o projeto foi estruturado e as decisões que foram tomadas. Este tipo de documentação está presente diretamente no código. Não está claro porque a DHT foi limitada a utilizar apenas 8 nós e o espaço de chaves apenas 0 a 198 (aliás, por que 198?). Não há problema em simplificar o código da DHT para funcionar apenas na máquina local mas também não haveria necessidade. O esquema de chaves * 25 não é o pedido no enunciado e não traz vantagem prática alguma à utilização de um espaço de chaves maior (Por que usar como primo 199? Qual é a necessidade de usar um primo?). Não implementa corretamente o milestone 2, e implementa parcialmente o 3 e o 1. Qual a razão de se utilizar o SHA-256 se vai usar no máximo 8 bits? A mensagem de TRANSFER é feita apenas na saida de um nó, mas não na entrada. |
Final
| RA | Projeto 1 | Projeto 2 | Final |
|---|---|---|---|
| 11001814 | 9.0 | 7.0 | 8.00 |
| 11004613 | 6.5 | 10 | 8.25 |
| 11021314 | 4.0 | 0.0 | 2.00 |
| 11025214 | 8.0 | 7.0 | 7.50 |
| 11027513 | 7.0 | 3.50 | |
| 11028613 | 9.0 | 9.5 | 9.25 |
| 11031115 | 8.5 | 6.0 | 7.25 |
| 11032414 | 0.00 | ||
| 11035011 | 6.5 | 10 | 8.25 |
| 11035014 | 9.0 | 9.5 | 9.25 |
| 11037213 | 0.00 | ||
| 11038215 | 8.5 | 6.0 | 7.25 |
| 11038216 | 0.00 | ||
| 11043111 | 10.0 | 0.0 | 5.00 |
| 11043313 | 0.00 | ||
| 11049914 | 0.0 | 0.00 | |
| 11053015 | 0.0 | 0.00 | |
| 11062715 | 7.0 | 2.1 | 4.55 |
| 11070111 | 0.00 | ||
| 11073415 | 4.5 | 6.0 | 5.25 |
| 11075613 | 4.0 | 6.0 | 5.00 |
| 11075614 | 4.0 | 6.0 | 5.00 |
| 11088512 | 0.00 | ||
| 11110012 | 7.0 | 2.1 | 4.55 |
| 11110915 | 4.5 | 6.0 | 5.25 |
| 11114710 | 2.3 | 1.15 | |
| 11115013 | 6.5 | 10 | 8.25 |
| 21002513 | 8.0 | 7.0 | 7.50 |
| 21017613 | 0.00 | ||
| 21023314 | 2.3 | 8.0 | 5.15 |
| 21028815 | 5.5 | 0.0 | 2.75 |
| 21032114 | 4.0 | 0.0 | 2.00 |
| 21036413 | 10.0 | 5.00 | |
| 21036615 | 4.0 | 6.0 | 5.00 |
| 21039614 | 8.0 | 4.00 | |
| 21044612 | 2.3 | 8.0 | 5.15 |
| 21068112 | 9.0 | 4.50 | |
| 11201722998 | 10.0 | 0.0 | 5.00 |