PPGCC, FACIN, PUCRS
Prof. Eduardo Augusto Bezerra
Porto Alegre, outubro de 2008
Trabalho Prático 2: Programação Diversitária
Explorar, na prática, o ciclo de desenvolvimento de um sistema tolerante a falhas baseado na técnica de programação diversitária.
Cada aluno possuirá uma responsabilidade específica no desenvolvimento e teste do sistema:
Escrever o módulo de um software de controle para um braço robô a ser utilizado em cirurgias. O módulo a ser implementado é o responsável pelo cálculo das coordenadas da ponta (ou "pinça") do braço robô, no plano cartesiano. O módulo recebe como entradas os valores EC, CH, alfa e beta. Os valores (absolutos) dos ângulos alfa e beta sao fornecidos por um resolver com precisão de 32 bits. A saída a ser fornecida é o par de coordenadas X, Y do ponto H, para cada configuração de EC, CH, alfa e beta. A figura a seguir representa o sistema graficamente.
As entradas encontram-se em um arquivo texto (entrada.txt), onde cada linha contém os quatro valores de entrada separados por um espaço. Por exemplo:
30 20 45 120
30 20 48 130
30 20 43 140
25 25 32 150
A primeira linha informa que EC = 30, CH = 20, alfa = 45, beta = 120, e assim sucessivamente. O programa deverá possuir uma função, estilo sub-rotina, para ler todo o arquivo de uma única vez e carregar as informações em uma estrutura de dados. Deverá possuir uma outra função para processar os dados, e gravar os resultados em um arquivo de saída, também no formato texto, contendo um par de coordenadas X, Y por linha, tambem separadas por um espaço (semelhante ao arquivo de entrada). Os arquivos de entrada e saída devem possuir o mesmo número de linhas, onde a primeira linha do arquivo de saída representa o resultado do processamento dos valores de entrada encontrados na primeira linha do arquivo de entrada e assim sucessivamente. O programa deverá possuir uma funcao main que aciona as funções de leitura de arquivo, processamento e gravação do arquivo de saída.
De forma a garantir um mínimo de “diversidade” no projeto do sistema, é solicitado aos desenvolvedores que não troquem nenhum tipo de informação sobre os requisitos ou detalhes de implementação. Qualquer duvida entrar em contato com o professor da disciplina, jamais com os demais colegas da turma. A troca de informações com os colegas (estruturas de dados utilizadas, dicas para leitura/escrita nos arquivos, etc...) certamente irá invalidar o experimento.
Obrigatoriamente, também para garantir um mínimo de diversidade, é importante uma distribuição adequada a nível de linguagens de programação utilizadas. Por exemplo, considerando o desenvolvimento de n versões diferentes, não seria adequado a implementação de uma versão em C, uma em C#, uma em C++ e 10 em Java. A linguagem de programação a ser utilizada deverá ser informada previamente ao professor da disciplina que irá controlar essa diversidade.
Também é importante notar que a apresentação do trabalho será na aula do dia 01/12/2008, e todas as versões, assim como o votador, terão que ser executados nessa aula. Essa apresentação/demonstração do trabalho será realizada em uma sala de aula laboratório da FACIN. Dessa forma, é importante que o programa seja desenvolvido em uma linguagem de programação/ambiente disponível na imagem padrão da FACIN. No momento da apresentação do trabalho não será possível realizar nenhuma instalação de software. Todo o software a ser entregue deverá ter sido compilado com as ferramentas disponíveis no laboratório da FACIN.
O modulo votador deverá ler os doze arquivos de saída gerados pelas n versões do software, e tomar a decisão sobre a posição correta do braço robô, para cada uma das configurações de entrada existentes. Esse módulo deverá levar em consideração o problema da comparação consistente, discutido no artigo SUSAN S . BRILLIANT, JOHN C. KNIGHT and NANCY G . LEVESON, "The Consistent Comparison Problem in N-Version Software", IEEE Transactions on Software Engineering, v. 15, n. 11, Nov. 1989, p. 1481-1485. O módulo deverá implementar uma estratégia para lidar com esse problema. Esse grupo deverá fornecer um relatório informando, para cada linha do arquivo de entrada, quais foram as respostas de cada versão. Essa informação será utilizada na validação do sistema pela equipe de teste. O formato desse arquivo segue o padrão dos demais, ou seja, cada linha contém os valores calculados para cada uma das versões, separados por um espaço. O arquivo possui o mesmo número de linhas do arquivo de entrada.
Para validar o sistema deverá ser projetada uma bateria de testes voltada nao apenas para o braço robô, mas também para o votador. Devem ser pensadas no máximo possível de situações que podem não terem sido previstas pelas equipes de desenvolvimento. O grupo responsável pela geração da bateria de testes possui a difícil tarefa de tornar visíveis os erros existentes no sistema tolerante a falhas. Quanto mais erros forem exercitados, mais bem sucedido será o trabalho do grupo que precisa "derrubar" o sistema. O grupo deverá gerar um arquivo de entrada a ser utilizado pelas n-versÕes no dia da apresentação, sendo que deverá ser definido também qual a saída esperada para cada uma das configurações de entrada. Essa informacao não deverá ser passada de forma alguma para os desenvolvedores, pois caso contrario existirá a tentativa de preparar os programas para as situações definidas no arquivo de entrada, o que levará a uma baixa avaliação do grupo responsável pela geração dos casos de teste por não ter conseguido forçar um número adequado de situações de falhas.
Esse grupo será o responsável por comparar os resultados obtidos pelo votador com os resultados esperados. Deverá apresentar tambem um relatório completo do sistema, informando, por exemplo, o número de acertos de cada versão gerando assim um ranking.
No lugar dos arquivos de saída, a equipe responsável pelo votador pode definir uma outra forma de recepção dos resultados das n-versões. Essa definição precisa ser informada, e detalhada junto aos desenvolvedores das versões.
Por exemplo, pode ser definido que as versões enviam via sockets um resultado (as duas coordenadas) por rodada. Sempre que o votador solicitar, receberá de cada versão um par de coordenadas, realiza a votação, fornece o resultado, e solicita um novo par de coordenadas, até que terminem as entradas para as n-versões. Essa seria uma execução bem mais realista.