Trabalho - Desenvolvimento de Aplicação Distribuída

Nesta página estão detalhados os procedimentos a serem seguidos para atribuição e desenvolvimento de uma aplicação distribuída usando as tecnologias estudadas durante as aulas de Sistemas Distribuídos. Este trabalho será parte integrante da 2a. nota da disciplina (2o. Bimestre). Exemplos de implementações de trabalhos desse tipo em turmas anteriores estão aqui (Markus, Manoel e Marco - EC - 2003) e aqui (Emerson - EC - 2003).

1) Objetivo: Implementar, utilizando a biblioteca de sockets, CORBA ou RMI (não apresentado em sala de aula) uma aplicação distribuída de acordo com a lista de sugestões apresentada em 2).

2) Sugestões de Aplicações Distribuídas para Implementação:

1. Servidor de mensagens

• Função básica: uma aplicação distribuída que possibilite o armazenamento, envio e recuperação de mensagens por clientes previamente cadastrados. Essa aplicação deve simular o comportamento de um servidor de mensagens eletrônicas e não-instantâneas, ou seja, deve simular um serviço de e-mail.

2. Controle de entradas em estacionamento

• Função básica: a aplicação deve simular o controle de entradas e saídas de veículos em um estacionamento. Programas clientes funcionam como “catracas eletrônicas” nas entradas do estacionamento, registrando entradas e saídas. Um programa servidor deve armazenar o estado atual das entradas e saídas.

3. Gerenciador de informações de máquinas em uma rede

• Função básica: programas clientes consultam informações sobre uma determinada máquina (o cliente especifica o nome da máquina, por exemplo) e um conjunto de informações sobre essa máquina deve ser informado. Exemplos de informações são: sistema operacional, capacidade de memória, capacidade de disco, modelo do processador, valores utilizados de processador, memória e disco, quantidade de usuários conectados, presença de serviços de rede como: servidor de ftp, servidor http, etc.

4. Servidor de serviços de processamento

• Função básica: essa aplicação deve fornecer determinados serviços a clientes remotos. Exemplos de serviços são: criação de pastas, conversão de arquivos (de .dvi para .pdf, de .doc para .html, por exemplo), informações de data e hora.

5. Implementação de algoritmos distribuídos de eleição

• Função básica: implementação de algoritmos distribuídos de eleição conforme estudados em sala de aula. Em específico, o grupo de estudantes que escolher esse trabalho deve focar o desenvolvimento dos algoritmos Bully e Anel. Este é um projeto interessante pois deve-se ter em mente que qualquer programa “participante” do sistema deve possuir as funções de cliente e servidor.

6. Implementação de algoritmos distribuídos para exclusão mútua

• Função básica: implementação de algoritmos distribuídos para exclusão mútua conforme estudados em sala de aula. O grupo de estudantes que escolher esse trabalho deve implementar, pelo menos, dois algoritmos, sendo que um desses deve ser o algoritmo distribuído (Ricarte e Agrawal) para exclusão mútua.

7. Mecanismos de gerenciamento (tolerância a falhas, balanceamento de cargas, serviços de nomes, consistência, etc.)

• Função básica: implementação de serviços de gerenciamento (tolerância a falhas, balanceamento de cargas, serviços de nomes, execução de servidores sob demanda) em ambientes distribuídos. O intuito aqui é implementar uma camada de software entre o cliente e servidor que executará serviços de gerenciamento a fim de manter a execução da aplicação funcionando a maior parte do tempo (tolerância a falhas), maximizar o desempenho (balanceamento de cargas) ou mesmo, fornecer flexibilidade (serviço de nomes, execução de servidores sob demanda) para a aplicação.

8. Aplicação Comercial Distribuida com Servidor Tolerante a Falhas

• Será implementado um sistema comercial simples a ser definido (Exemplo: Cadastro e baixa de produtos em estoque) desenvolvido de forma distribuida utilizando o modelo MVC. A camada View ficará nos clientes. A camada Controller da aplicação ficará em um servidor de gerenciamento de informações. Camada Model em um servidor de Banco de Dados (BD), lembrando que todos estarão implementados de forma distribuida. Entre as funcionalidades proposta, deseja-se criar um gerenciamento para tolerancia de falhas, sendo implementado na camada Controller. Se o servidor de gerenciamento ficar indisponível, um outro servidor tomará as atividades de Controller da aplicação, recebendo os dados da camada View(Cliente), e enviando para Model(Servidor de BD). Deseja-se implementar também um forma do Controller manter os Clientes atualizados com as informações que estão trafegando para o BD.

3) Alocação dos Trabalhos

3) O que deve ser implementado?

• Independente da aplicação a ser escolhida, cada grupo deverá implementar, pelo menos, cinco métodos no servidor e, além disso, deve implementar programa(s) cliente(s) que utilizem os métodos implementados.

• O código da aplicação deverá ser completamente documentado. Em especial, as classes e métodos disponíveis para requisições por parte do cliente.

• Arquivo README que indica: os requisitos necessários para execução, sintaxe para compilação e execução da aplicação, além, de um exemplo de como executar a aplicação.

4) Sugestão de metodologia?

1. Trabalho em duplas. No pior dos casos, pode ser individual. Trabalhos em trios não serão aceitos.

2. Definição da tecnologia utilizada (sockets/CORBA/RMI/...) e entendimento dos recursos a serem implementados.

3. Modelagem da aplicação: construção diagrama de classes, seqüências, etc.

4. Implementação de um protótipo da aplicação. Implementar um método (recurso) definido nas etapas 2) e 3). Testar essa implementação exaustivamente.

5. Após a validação da etapa 4), implementar os demais métodos (recursos) definidos para a aplicação.

6. Projetar e executar casos de testes sobre a aplicação implementada. Quanto mais testes, mais possibilidade de encontrar bugs, consertá-los e garantir a corretude.

7. Troca de informações constante entre os componentes do grupo. É recomendável que os componentes troquem as funções (quem estava projetando mude para a implementação, quem estava implementado mude para o projeto) em determinados momentos a fim de que todos possam ter experiência com as diferentes fases.

5) Qual o Cronograma ?

• 11/09 - Início do trabalho

• 02/10 – 1o. Checkpoint: É esperado que o grupo tenha em mãos o projeto da aplicação. Idealmente, deve-se apresentar um ou mais diagramas de maneira a elucidar o que será implementado.

• 16/10 – 2o. Checkpoint: O grupo deve apresentar a versão 0.1 de sua aplicação distribuída. O foco aqui deve ser a conclusão da etapa 4) sugerida como metodologia.

• 30/10 – 3o. Checkpoint: Neste ponto é esperado que a maior parte da aplicação tenha sido implementada.

• 13/11 - Último Checkpoint: Últimas correções na implementação. Versão inicial do relatório.

• 26/11 – Entrega (impressa) e apresentação do trabalho (uma semana após a prova):

  • Entregar relatório indicando:

1. O propósito da aplicação distribuída que foi implementada

2. O que foi implementado

3. O que faltou implementar

4. A sintaxe para execução da aplicação

5. Bugs/Falhas detectados e não corrigidos

6. Dificuldades encontradas durante o desenvolvimento do trabalho

7. Conclusões

• Enviar (para email do professor) o código fonte da aplicação juntamente com o arquivo README.

6) Como será a avaliação?

• A avaliação da trabalho constará das avaliações parciais dos checkpoints (cada checkpoint terá peso 1);

• da avaliação do(s) documento(s) e software(s) entregue(s) (peso 2);

• da avaliação final de todo o trabalho e da apresentação (peso 4);

• Bônus (peso 1.5): organização e documentação do código, arquivo README, scripts para configuração e execução, clareza na explicação do relatório, participação no projeto;

7) Dicas/Sugestões

• Tentem aproveitar ao máximo os momentos de checkpoint em sala de aula.

• Procurem iniciar o trabalho o quanto antes. O tempo voa!

• Documentar o código! Isso facilitará o trabalho colaborativo entre a dupla, além de ajudar a relembrar o que estava sendo feito no dia anterior.

• Estudem a linguagem Java! É essencial entender bem uma linguagem que queremos utilizar em um trabalho. Além do mais, isso possibilitará que a etapa de implementação não seja interrompida por dúvidas na linguagem de programação.

8) Perguntas frequentes:

P: O que será feito em dia de Checkpoint?

R: Nas datas marcadas para checkpoints, os alunos deverão se dirigir ao laboratório 2, no horário da aula de SD, e devem se reunir em torno de seus respectivos grupos. O professor passará por todos os grupos fazendo uma breve entrevista. Nessa entrevista será averiguado o andamento do trabalho, dificuldades encontradas até o momento e o que é pretendido para o próximo checkpoint. No dia de checkpoint os grupos devem aproveitar o horário para: adiantar o desenvolvimento do trabalho, tirar dúvidas, pedir sugestões, informar alterações no projeto original com o professor.

P: Se faltar no dia do checkpoint, fica com 0?

R: Há duas possibilidades: 1) Se souber, previamente, que irá faltar em dia de checkpoint, a dupla deve avisar ao professor que irá agendar um horário anterior ao dia do checkpoint. 2) caso a falta seja devido a um imprevisto, a dupla deve procurar o professor e deve justificar a ausência e, após isso, o professor marcará um horário para a entrevista. Faltas sem justificativa, aí sim, terão 0 como nota do checkpoint.

P: As notas serão as mesmas para os componentes da dupla?

R: Não. As entrevistas serão com a dupla mas a nota é individual. O fato de um membro da dupla faltar em dia de checkpoint não implica que a entrevista será cancelada. Por isso, é extremamente importante que ambos dividam o trabalho e, continuamente, atualizem-se quanto ao desenvolvimento do mesmo.

P: O que devo privilegiar: implementar todo o conteúdo de uma etapa ou implementar todas as etapas?

R: Se não houver tempo hábil, é melhor implementar o mínimo necessário em uma etapa e partir para a próxima.

P: O que fazer em caso de dúvidas no entendimento do trabalho (situações não cobertas pela especificação da linguagem, ausência de detalhes na atribuição das tarefas, etc.)?

R: Procure o professor o quanto antes: pessoalmente ou enviando mensagem eletrônica com subject: "Dúvidas: Trabalho – Sistemas Distribuídos". Nesse último caso, procure discorrer sucintamente a sua dúvida. Além disso, aproveite bem os encontros de checkpoint para retirar as dúvidas, sugerir alterações na atribuição do trabalho, justificar suas escolhas. Isso contará na sua participação e dedicação do trabalho.

P: O que será feito no dia 26/11?

R: Nessa data, todos o grupos devem comparecer no laboratório 2. Será feito um sorteio da ordem de apresentação (qual grupo será o primeiro a apresentar, o segundo, e assim por diante). Cada grupo terá 15 minutos para apresentação do trabalho + 2 minutos para perguntas da platéia. A apresentação deve tomar como base o relatório/artigo entregue. O grupo que está apresentando é livre para fazer demonstrações da aplicação desenvolvida desde que seja obedecido o limite de tempo. Todos os componentes do grupo devem apresentar. O tempo será controlado de forma que as apresentações não passarão de 15 min.

P: Estou tendo problemas com o outro componente da dupla. O que devo fazer?

R: Uma das motivações desta tarefa é justamente melhorar a habilidade de trabalho em grupo. Nesse sentido, a dupla deve conversar bastante, procurando resolver todos os conflitos que porventura possam surgir. Saber ouvir opiniões, discutir idéias educadamente, ceder sobre pontos de vistas e dividir tarefas é o que aprendemos de melhor em um trabalho em grupo. Certamente, cada membro pode contribuir positivamente  para a nota do outro colega da dupla. Mas,  caso um dos membros "desista" do trabalho, o outro membro pode continuar a implementação que o trabalho será avaliado levando isso em consideração.

P: Se obter nota máxima em todos os itens da avaliação ficarei com 11.5?

R: Não. A nota máxima é 10! Além disso, esses pontos não são cumulativos.