PPGCC, FACIN, PUCRS
Profs. Drs. Avelino Zorzo e Eduardo Bezerra
Porto Alegre, Setembro de 2006
Trabalho Pratico 2: Programacao Diversitaria
Explorar, na pratica, o ciclo de desenvolvimento de um sistema tolerante a falhas baseado na tecnica de programacao diversitaria.
A turma e' dividida em grupos de dois alunos, e cada grupo possuira' uma responsabilidade especifica no desenvolvimento e teste do sistema.
G1 .. G4 – implementacao das n-versoes
G5 – implementacao do votador
G6 – geracao das entradas e saidas (teste do sistema)
Escrever o modulo de um software de controle para um braco robo a ser utilizado em cirurgias. O modulo a ser implementado e' o responsavel pelo calculo das coordenadas da ponta (ou “pinça”) do braco robo, no plano cartesiano. O modulo recebe como entradas os valores EC, CH, alfa e beta. Os valores (absolutos) dos angulos alfa e beta sao fornecidos por um resolver com precisao de 32 bits. A saida a ser fornecida e' o par de coordenadas X, Y do ponto H, para cada configuracao de EC, CH, alfa e beta. A figura a seguir representa o sistema graficamente.
As entradas encontram-se em um arquivo texto, onde cada linha contem os quatro valores de entrada separados por um espaco.. 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 devera' possuir uma funcao, estilo sub-rotina, para ler todo o arquivo de uma unica vez e carregar as informacoes em uma estrutura de dados. Devera' possuir uma outra funcao para processar os dados, e gravar os resultados em um arquivo de saida, tambem no formato texto, contendo um par de coordenadas X, Y por linha, tambem separadas por um espaco (semelhante ao arquivo de entrada). Os arquivos de entrada e saida devem possuir o mesmo numero de linhas, onde a primeira linha do arquivo de saida representa o resultado do processamento dos valores de entrada encontrados na primeira linha do arquivo de entrada e assim sucessivamente. O programa devera' possuir uma funcao main que aciona as funcoes de leitura de arquivo, processamento e gravacao do arquivo de saida.
De forma a garantir um minimo de “diversidade” no projeto do sistema, e' solicitado aos grupos que nao troquem nenhum tipo de informacao sobre os requisitos ou detalhes de implementacao. Qualquer duvida entrar em contato com o professor da disciplina (Bezerra), jamais com os demais colegas da turma. A troca de informacoes com os colegas (estruturas de dados utilziadas, dicas para leitura/escrita nos arquivos, etc...) certamente ira' invalidar o experimento.
Obrigatoriamente, tambem para garantir um minimo de diversidade, o seguinte devera' ser obedecido:
G1, linguagem C no Linux;
G2, linguagem C++ (com orientacao a objetos) no Linux;
G3, Linguagem C++ (com orientacao a objetos) no Windows;
G4, Linguagem Java.
O modulo votador devera' ler os quatro arquivos de saida gerados pelos grupos G1 .. G4, e tomar a decisao sobre a posicao correta do braco robo, para cada uma das configuracoes de entrada existentes. Esse modulo devera' levar em consideracao o problema da comparacao 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 modulo devera' implementar uma estrategia para lidar com esse problema. Esse grupo devera' fornecer um relatorio informando, para cada linha do arquivo de entrada, quais foram as respostas de cada grupo. Essa informacao sera' utilizada na validacao do sistema pelo grupo G6. O formato desse arquivo segue o padrao dos demais, ou seja, cada linha contem os valores calculados para cada um dos quatro programas, separados por um espaco. O arquivo possui o mesmo numero de linhas do arquivo de entrada.
Para validar o sistema devera' ser projetado uma bateria de testes voltada nao apenas para o braco robo, mas tambem para o votador. Devem ser pensadas no maximo possivel de situacoes que podem nao terem sido previstas pelas equipes de desenvolvimento. O grupo responsavel pela geracao da bateria de testes possui a dificil tarefa de tornar visiveis os erros existentes no sistema tolerante a falhas. Quanto mais erros forem exercitados, mais bem sucedido sera' o trabalho do grupo que precisa “derrubar” o sistema. O grupo devera' gerar um arquivo de entrada a ser utilizado pelos grupos no dia da apresentacao, sendo que devera' ser definido tambem qual a saida esperada para cada uma das configuracoes de entrada. Essa informacao nao devera' ser passada de forma alguma para os grupos G1..G5, pois caso contrario existira' a tentativa de preparar os programas para as situacoes definidas no arquivo de entrada, o que levara' a uma baixa avaliacao do grupo G6 por nao ter conseguido forcar um numero suficiente de situacoes de falhas.
Esse grupo sera' o responsavel por comparar os resultados obtidos pelo votador (G5) com os resultados esperados (G6). Devera' apresentar tambem um relatorio completo do sistema, informando, por exemplo, o numero de acertos de cada grupo gerando assim um ranking.