PPGCC, FACIN, PUCRS
Prof. Eduardo Augusto Bezerra
Porto Alegre, novembro de 2009
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 diversas 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 07/12/2009, e todas as versões, assim como o votador, terão que ser executadas 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 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. Deverá ser fornecido 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 será utilizada uma bateria de testes (JÁ ESTÁ PRONTA) voltada nao apenas para o braço robô, mas também para o votador. Será realizada uma comparação dos resultados obtidos pelo votador com os resultados esperados. Será apresentado um relatório completo do sistema, informando, por exemplo, o número de acertos de cada versão gerando assim um ranking.