TRATAMENTO DE DEAD CODES EM SOFTWARE DE USO AERONÁUTICO

Transcrição

1 TRATAMENTO DE DEAD CODES EM SOFTWARE DE USO AERONÁUTICO Renner Costa Martins 1, Sergio Roberto Matiello Pellegrino 2, Jony Santellano 3 1 ITA, Praça Marechal Eduardo Gomes, 50, São José dos Campos, São Paulo, Brasil, martins.renner@gmail.com 2 ITA, Praça Marechal Eduardo Gomes, 50, São José dos Campos, São Paulo, Brasil, pell@ita.br 3 ITA, Praça Marechal Eduardo Gomes, 50, São José dos Campos, São Paulo, Brasil, jony@ita.br Abstract: The objective of this paper is to propose a process for treatment of Dead Codes in software used on aircraft systems, attending the requirements of the aeronautical standard RTCA/DO-178B. Keywords: Dead Code, RTCA/DO-178B, Software embarcado de uso aeronáutico. 1. INTRODUÇÃO O tópico de interesse deste trabalho é a existência de Dead Codes, que é código fonte que não é percorrido pela execução normal do software e que não está associado a nenhum requisito da especificação. O padrão RTCA/DO- 178B, utilizado para desenvolvimento de software de uso aeronáutico, estabelece que a existência de Dead Codes em software aeronáutico não é permitida, devendo ser tratada apropriadamente [1]. A preocupação da RTCA/DO-178B é justificada pela falta de rastreabilidade inerente à existência de Dead Codes, que significa que pode haver problemas na especificação. Outra incerteza associada à Dead Codes é a existência de código fonte que não foi testado. Por esses e outros problemas associados, Dead Codes é o principal motivador deste trabalho. O objetivo deste trabalho é apresentar um processo para tratamento de Dead Codes em software aeronáutico, que tem como premissa atender os critérios do padrão RTCA/DO- 178B. A finalidade desse processo é dar maior base para que o desenvolvedor de software aeronáutico se assegure que as ocorrências de Dead Codes foram identificadas e tratadas adequadamente, dando maior confiança quanto ao cumprimento dos requisitos de aeronavegabilidade de um sistema aeronáutico onde o software é embarcado 2. O PADRÃO RTCA/DO-178B Criado na década de oitenta pela Radio Technical Commission for Aeronautics, Inc.(RTCA), o padrão RTCA/DO-178B estabelece os procedimentos necessários para que o fabricante de software embarcado de uso aeronáutico demonstre que seu produto foi construído atendendo aos critérios de aeronavegabilidade. A importância da RTCA/DO-178B no ambiente de certificação aeronáutica é atestada pela emissão da AC- 115B pelo FAA, que indica o padrão como meio aceito para a análise de software embarcado de uso aeronáutico dentro do processo de certificação [2]. Por ser uma autoridade de certificação de referência mundial, a diretriz do FAA foi seguida por diversas autoridades, como a EASA e a ANAC. Por sua importância na indústria de aviação, esse trabalho seguirá os critérios definidos pela RTCA/DO-178B para software embarcado de uso aeronáutico. A RTCA/DO-178B é a terceira versão do padrão, e se diferenciou das demais ao dar grande ênfase aos testes baseados em requisitos, que verificam se as funcionalidades previstas na especificação são atendidas. Em complemento aos testes baseados em requisitos, prevê-se também o uso dos testes de cobertura estrutural de código para verificar se todo o código foi percorrido durante a realização dos testes. Com isso ficou evidente a importância do processo de verificação de software dentro do ciclo de vida do produto, definido pela RTCA/DO-178B Processo de Verificação de Software O processo de Verificação de Software é a atividade responsável pela detecção e registro de erros, cuja remoção fica a cargo do processo de desenvolvimento de software. O cumprimento dessa etapa é realizado por revisões, análises, desenvolvimento e execução de casos de teste e seus procedimentos. Nas tarefas de revisão e análise, o software em questão terá seus requisitos, arquitetura e código fonte avaliados, principalmente quanto a sua precisão, completeza e reverificabilidade, isto é, sua capacidade de ser novamente analisado e produzir os mesmos resultados verificados anteriormente. Complementar à análise feita, o desenvolvimento dos casos de testes fornecem uma avaliação adicional da consistência e completeza dos requisitos de software previstos. Por fim, a execução dos procedimentos de testes demonstra que o software verificado cumpre com os requisitos necessários. O processo de verificação de software é composto essencialmente por atividades de revisão, análise e testes. Nesse contexto, pode-se afirmar que as atividades de testes têm dois objetivos principais: demonstrar que os requisitos foram funcionalmente atendidos pelo software desenvolvido; tratar do grau de confiança com que os erros, que poderiam resultar em condições de falha, foram detectados e removidos. Nota-se, desses dois objetivos, que 1 Serra Negra, SP - ISSN

2 Tratamento de Dead Codes em Software de uso Aeronáutico Renner Costa Martins, Sergio Roberto Matiello Pellegrino, Jony Santellano eles são complementares e que para se atender a um deles, deve-se também atender o outro. A Figura 1 mostra uma visão geral do processo de teste de software, que abrange três tipos de testes, cujos objetivos são: 1. Hardware/Software Integration Tests: verificar a correta operação do software em seu ambiente real de execução; 2. Software Integration Tests: verificar as relações entre os requisitos de software e sua implementação, dentro da arquitetura de software estabelecida; 3. Low-Level Tests: verificar a implementação dos requisitos funcionais de software, considerados de baixo nível, ou seja, aqueles que são mais detalhados quanto à funcionalidade desejada. A região identificada por Unimplemented Function indica que existem requisitos que não foram cobertos pelo código criado. Esse caso é normalmente identificado pela execução dos testes baseados em requisitos, e não pela análise de cobertura estrutural do código. Por sua vez, a região do código que não é sobreposta pela região dos requisitos, identificada na figura por Unspecified Function, trata dos trechos de código que não têm correspondência nos requisitos testados, que são identificados por uma análise estrutural do código [3]. Figura 2 Sobreposição de requisitos e implementação [3] Figura 1 Processo de Teste de Software [1] Além dos objetivos de cada tipo de teste mencionado, podemos verificar na Fig. 1 que o processo de testes de software envolve também a análise de cobertura dos testes realizados. Essa análise é representada na figura pelos itens Software Requirements Coverage Analysis e Software Structure Coverage Analysis, sendo esse último, que trata da cobertura estrutural de código, de grande relevância para esse trabalho Cobertura Estrutural de Código Dentro do processo de verificação de código a cobertura estrutural mede quanto da estrutura do software foi testada. Com essa medida, é possível saber se a execução dos testes de cobertura dos requisitos exercitou toda a estrutura do código e, assim, determinar o nível de qualidade do software analisado[1]. Na Figura 2 é exibido um esquema que ilustra o significado de cobertura estrutural de código e a sua relação com os requisitos de software. A área de sobreposição representa a identificação do código fonte exercitado pelos requisitos, sendo que esse código pode estar correto, representado na figura por Correct Function, ou não, representado na figura por Incorrect Function, caso não atenda aos requisitos testados nos casos de testes. A cobertura estrutural de código possibilita determinar se existem estruturas do código que não foram exercitadas pelos procedimentos de testes baseados nos requisitos. Essas estruturas identificadas podem ser resultado dos seguintes casos [1]: 1. Fornecer evidência que a estrutura de código foi verificada no grau requerido; 2. Fornecer meios para suportar a ausência de Dead Codes; 3. Estabelecer a robustez dos testes de cobertura de requisitos. Quanto à detecção de Dead Codes, a cobertura estrutural de código permite indicar com que extensão os casos de testes baseados em requisitos executaram o código e, por consequência, revelam os trechos de código que não foram executados. 3. DEAD CODES Em termos gerais, define-se Dead Code como qualquer parte do código fonte cuja existência não afeta a execução normal do programa. Há dois casos principais de Dead Code: 1. Código inútil: Código cuja execução não afeta o restante do programa; 2. Código não alcançável: código que nunca é alcançado pela execução do programa e, portanto, também nunca a afeta. Abaixo, segue a definição de Dead Code dada pela norma RTCA/DO-178B: Dead code - Executable object code (or data) which, as a result of a design error cannot be executed (code) or used (data) in an operational configuration of the target 2 Serra Negra, SP - ISSN

3 computer environment and is not traceable to a system or software requirement. An exception is embedded identifiers.[1] A partir do texto, observa-se que a definição de Dead Code, segundo a RTCA/DO-178B, se atém à definição de Código Não Alcançável e é com essa premissa que esse trabalho foi construído. Portanto, doravante, será referenciada por Dead Code qualquer ocorrência de código não alcançável em um programa Ocorrências de Dead Codes As ocorrências típicas de Dead Code encontram-se relacionadas ao uso das seguintes práticas: 1. Desvio incondicional; 2. Instrução de retorno; 3. Expressões de controle de fluxo; 4. Expressões de controle de fluxo com curto-circuito Desvio incondicional Dá-se o nome de desvio incondicional a qualquer instrução que tenha o objeto de direcionar o fluxo de execução do programa para um ponto não subseqüente à instrução. Expressões como goto, break, continue possuem essa característica e são fontes de possíveis Dead Codes. O exemplo ilustrado na Tabela 1 exibe uma ocorrência de Dead Code em um trecho de código em C que utiliza um desvio incondicional com o uso de uma instrução goto. No trecho, percebe-se que a linha 4 nunca será executada, já que na linha 2 há um desvio para a linha 6. Tabela 1 Dead Code com o uso de desvio incondicional goto rotulo;... printf("não passou por aqui\n");... rotulo: printf("a linha 3 não foi executada"); Instruções de retorno Uma instrução de retorno é utilizada em uma subrotina para retornar a execução de um programa para o ponto onde a subrotina foi chamada. Em linguagens como Ada, C, C++, C# e Java essa instrução é representada pela palavra reservada return. O mal uso de return pode resultar em Dead Codes, caso ele esteja colocado imediatamente antes de alguma outra expressão dentro de uma subrotina. A Tabela 2 exibe um exemplo de um trecho de código em C, onde a localização da expressão return resulta em uma ocorrência de Dead Code. Nesse exemplo, nota-se que a linha 6 nunca será executada, já que a cláusula return direciona a execução do programa para o ponto onde a subrotina soma foi chamada. Tabela 2 Dead Code com o uso de uma expressão return int soma(int x, int y) { int z; z=x+y; return z; printf("não passou por aqui\n"); } Expressões de Controle de Fluxo Expressões de controle de fluxo também são fontes de Dead Code, pois o uso incorreto das condições a serem avaliadas pode causar a execução de apenas algum, ou alguns, dos caminhos possíveis. O caso mais simples dessa ocorrência de Dead Codes é resultado do mal uso de expressões if. A Tabela 3 ilustra um código em Matlab que contém um Dead Code causado pelo uso inadequado da expressão if, graças a uma variável imutável estabelecida antes da execução do if. No caso citado, o if da linha 5 só é avaliado de uma maneira, true, já que a variável utilizar_vento foi definida com o valor 1. Tabela 3 Dead Code com o uso de expressões de controle de fluxo % utilizar_vento determina o uso do vento % caso utilizar_vento==0 -> Sem vento % caso utilizar_vento==1 -> Com vento utilizar_vento=1; if(utilizar_vento~=0) utilizar_vento=1; disp('>>> Dinamica Com Vento'); else disp('>>> Dinamica Sem Vento'); end; A ocorrência do caso descrito na Tabela 3 também se aplica ao uso de outras expressões de controle de fluxo, tais como while, for, switch, etc Expressões de Controle de Fluxo com Curto- Circuito O uso de múltiplas condições em expressões de controle de fluxo podem acarretar na avaliação de apenas uma delas, caso essa condição seja suficiente para a tomada de decisão em uma cláusula if, while, for, switch, etc. A esses casos dáse o nome de curto-circuito. A existência de curto-circuitos também é fonte de Dead Codes, porém de natureza um pouco diferente daquela apresentada na seção Nesses casos, a ocorrência de Dead Codes se dá em uma das condições da expressão de controle de fluxo, que não é avaliada. 3 Serra Negra, SP - ISSN

4 Tratamento de Dead Codes em Software de uso Aeronáutico Renner Costa Martins, Sergio Roberto Matiello Pellegrino, Jony Santellano A Tabela 4 apresenta um exemplo do Matlab de Dead Code com o uso de curto-circuito. Na linha 4, a expressão (a/b > 18.5) nunca será avaliada, pois na linha 3 a variável b é definida como 0, o que resolve a expressão (b ~= 0) && (a/b > 18.5) apenas com o primeiro termo, (b ~= 0). Tabela 4 Dead Code com o uso de expressões de controle de fluxo com curto-circuito %It doesn't make sense to evaluate the % relation on the right if the divisor, b, is zero. b=0; x = (b ~= 0) && (a/b > 18.5); 3.2. Ocorrências de Dead Codes Relacionadas à Execução do Software Uma observação importante deve ser feita a respeito das ocorrências de Dead Codes relacionadas ao uso de expressões de controle de fluxo, com ou sem curto-circuito: ambas foram demonstradas como dependentes da existência de algum trecho de código mal construído. Porém, essas ocorrências apresentadas também podem existir sem o trecho de código mal construído, pois podem surgir durante a execução do programa. Essa condição está relacionada principalmente ao conjunto dos requisitos do software, que podem possuir casos de testes que não percorrem algum trecho de código fonte, indicando-o como Dead Code. A detecção e eliminação de Dead Codes também devem levar em conta as ocorrências de código não executado, devido a falhas na especificação e em seus casos de testes resultantes. Essa situação será abordada mais adiante Problemas Relacionados A existência de Dead Code pode causar uma série de efeitos indesejáveis que diminuem a confiabilidade da qualidade do software quanto à sua aderência ao processo de desenvolvimento. Entre os problemas causados por Dead Codes, encontram-se: Recursos de disco rígido ocupados desnecessariamente: a existência de Dead Codes implica em códigos maiores do que o necessário. Esse aspecto, caso não seja realizado algum tipo de otimização do código, resulta em maior espaço ocupado pelo código objeto executável. Em alguns ambientes esse fator pode ser crítico e afetar o desempenho de algumas funcionalidades do programa. Recursos de memória ocupados desnecessariamente: da mesma forma que há a ocupação desnecessária de espaço em disco, há a ocupação desnecessária de recursos de memória. Já que Dead Codes resultam em código objeto executável de tamanho maior do que o necessário, o espaço ocupado pelo programa na memória também será maior. Novamente, essa situação é aplicável aos casos onde não foi feita nenhuma melhoria no código fonte durante a compilação e geração do programa executável. Comprometimento da legibilidade do código: boa legibilidade do código depende extremamente de boas práticas de codificação. Ou seja, é uma tarefa árdua e trabalhosa que exige muito tempo das pessoas envolvidas. Quanto mais complexo um programa, maior é a dificuldade que alguém terá para entender o código analisado. Especificamente, Dead Codes tornam essa tarefa ainda mais complicada, pois, além de aumentarem desnecessariamente a complexidade de algum software, não possuem ligação com o restante do código analisado. Manutenção do código é dificultada: no contexto de manutenção de software, Dead Codes adicionam trabalho desnecessário ao processo. Tempo e esforço serão gastos na análise e manutenção de código que não está ligado a nenhuma funcionalidade do programa e que, portanto, é inútil para sua execução. Possível fonte de erros na execução do software: Dead Codes traz também a condição de trechos de código que não foram testados. Dependendo das condições de execução e de possíveis alterações no projeto, Dead Codes podem passar à condição de Live Codes não testados, que são, na verdade, fonte de possíveis erros não identificados e tratados na fase correta do ciclo de desenvolvimento do software. Requisitos não rastreáveis: a existência de Dead Codes significa também a existência de código fonte que não tem ligação com nenhum requisito do software. Isso implica na possibilidade de requisitos não atendidos completamente, pois alguma funcionalidade do software deixou de ser executada devido à existência de uma condição de Dead Code. Devido a esses, e possíveis outros problemas, condições de existência de Dead Codes devem ser detectadas, analisadas e, finalmente, eliminadas Detecção Em essência, a detecção de Dead Code é um processo ligado à verificação de código. Esse processo envolve a análise crítica do código fonte do software para identificar trechos de código que não são executados em qualquer condição. Graças à grande variedade de casos de Dead Code, sua detecção pode envolver atividades de análise estática de código e de análise de cobertura estrutural de código. Isso é necessário porque alguns tipos de Dead Code têm sua existência dependente da execução do software. Isso significa que esses tipos de Dead Codes estão relacionados a um conjunto de requisitos, seus respectivos casos de testes e da forma como eles são atendidos durante a execução normal do software. Assim, parte da tarefa de detecção de Dead Codes, está relacionada ao campo de análise estática de código. Esse campo realiza a análise do software sem a necessidade de executá-lo, fornecendo informações úteis para a verificação da qualidade do software analisado. Normalmente, esse processo pode ser feito por inspeção, ou revisão, de código, porém, outra abordagem de análise estática correntemente utilizada é o uso de gráficos de controle de fluxo do software. Com essa abordagem, basta verificar os blocos de código que não possuem nenhuma ligação na estrutura 4 Serra Negra, SP - ISSN

5 montada para o programa para identificar os trechos que não são alcançáveis. Na seção 3.2, foram discutidos alguns casos de Dead Codes que podem ser detectados apenas pela análise do comportamento do software durante a sua execução. Essa tarefa pode ser realizada por instrumentação de código, que aponta os trechos de código que foram executados a partir do uso de algumas funcionalidades. A escolha dessas funcionalidades está ligada ao conjunto de requisitos do software e pela definição dos casos de testes que devem ser utilizados para verificá-los. Com isso, a detecção desses Dead Codes se torna um problema de análise de cobertura estrutural de código. Com a análise estrutural de código, são identificados todos os trechos de códigos percorridos pela execução dos casos de testes referentes aos requisitos do programa. Assim, identificam-se também os trechos de código que não foram executados pelos testes Eliminação A realização das análises estática e dinâmica do código fonte terão como resultado a identificação dos casos de Dead Codes existentes em um programa. Esses resultados possibilitam a eliminação desses casos sem danos à execução esperada do software, de acordo com a sua especificação. Entende-se por eliminação de Dead Codes o processo que pode tomar as seguintes abordagens: 1. Remoção do trecho de código identificado: o Dead Code identificado é removido do programa, deixando de existir. 2. Transformar o caso de Dead Code em um trecho de código executável: por meio de ajustes no código fonte, ou em algum processo do ciclo de desenvolvimento, o Dead Code passa a ser um trecho de código executável. A escolha da abordagem do processo de eliminação de Dead Codes está sujeito às características de cada caso, identificadas pela sua detecção. Não há uma única solução para todos os tipos de Dead Codes, e, por isso, deve ser feita uma análise mais profunda de cada caso para determinar como será feita a eliminação do Dead Code. 4. PROCESSO PARA TRATAMENTO DE DEAD CODES Nessa seção este trabalho propõe um processo para ser utilizado no tratamento de Dead Codes em software embarcado de uso aeronáutico. Para dar o tratamento adequado a Dead Codes, são abordadas as atividades necessárias para classificação, detecção, eliminação e registro de Dead Codes, que serão descritas nas próximas seções. Com isso pretende-se atender ao objetivo do trabalho que é propor um processo para tratamento de Dead Codes em software embarcado de uso aeronáutico Classificação A definição de Dead Codes tem como itens chaves a não rastreabilidade de uma funcionalidade a, pelo menos, um dos requisitos do software e a não execução dessa mesma funcionalidade, durante o funcionamento normal do programa. O primeiro item é de fácil análise e entendimento já que é coberto pela análise de rastreabilidade dos requisitos do software e é resultado de uma falha no processo de garantia dessa rastreabilidade. Porém, o segundo item gera algumas nuances quanto à sua definição, pois o fato de uma função não ser executada pode depender de dois fatores: a geração do software em si e a cobertura do código quanto a um requisito. A existência desses dois fatores motivou a criação, pelo autor deste trabalho, de uma classificação de Dead Codes, baseada na maneira em que ocorrem. A intenção deste trabalho, ao criar essa classificação, é direcionar as atividades de eliminação de Dead Codes de acordo com suas características. Com isso, as ocorrências de Dead Codes são classificadas em Dead Codes Estáticos ou Dinâmicos. A criação do software pode incorporar erros de programação, que façam surgir funções que não são executadas em nenhuma condição, independente dos requisitos exercitados. Mesmo que não haja nenhum erro no levantamento de requisitos, nas funcionalidades previstas e nas condições de uso do programa, a função analisada não será executada. Aos casos de Dead Codes surgidos nessas condições será dada a classificação de Dead Codes Estáticos, graças a sua natureza independente da execução do software. Em contrapartida, Dead Codes Dinâmicos são as ocorrências geradas pela falta de cobertura de uma função, seja por erro no levantamento de requisitos, ou na abordagem utilizada para cobertura estrutural de código aplicada. Essa classificação é dependente da execução do software, pois apenas dessa maneira é possível identificar a existência desses casos de Dead Codes. Apesar de suas naturezas divergentes, ambas as classificações são bastante interligadas, pois a existência de um caso de Dead Code Dinâmico pode estar ligada a existência de um caso de Dead Code Estático, e vice-versa Detecção Considerando o processo de detecção de Dead Codes Estáticos, é observado que a tarefa de inspeção do software, para realizar a sua análise estática, é bastante árdua. Essa dificuldade existe, pois quanto mais complexo e maior um programa, maior será a quantidade de elementos para serem analisados. Por esse motivo, a análise estática do software pode ser precedida por técnicas de análise de cobertura estrutural que analisa código fonte. Com isso pode-se dividir a tarefa de detecção de Dead Codes Estáticos em duas fases: Análise de cobertura estrutural de software: nessa etapa são detectados os casos de Dead Codes Dinâmicos, que, eventualmente, poderão ser classificados como Dead Codes Estáticos. 5 Serra Negra, SP - ISSN

6 Tratamento de Dead Codes em Software de uso Aeronáutico Renner Costa Martins, Sergio Roberto Matiello Pellegrino, Jony Santellano Análise estática do software: consiste em uma análise estática das funcionalidades identificadas durante a análise de cobertura estrutural, para verificar quais deles são Dead Codes Estáticos. Na segunda etapa, as funcionalidades que são candidatas à classificação de Dead Code recebem uma análise mais específica, por inspeção do código do software. Com essa análise, pretende-se checar os blocos de funcionalidades não percorridos pelos testes, identificados na primeira etapa, classificando-os definitivamente como Dead Code Estáticos. Como mencionado, o processo de detecção de Dead Codes Dinâmicos pode ser realizado pela análise do programa durante sua execução. As técnicas de análise de cobertura estrutural do software têm como objetivo detectar esses casos e podem ser implementadas por simples instrumentação de software, ou pelo uso de ferramentas adequadas para isso. Mesmo com a detecção de Dead Codes Dinâmicos, é importante realizar também a análise estática das funcionalidades identificadas para verificar se não se tratam de Dead Codes Estáticos. Novamente, a natureza diferenciada de cada um dos dois tipos de Dead Codes torna essa tarefa necessária. Ao se detectar um caso de Dead Code Dinâmico, foram identificadas apenas as características específicas surgidas pela execução do programa. Porém, essa identificação não remove a possibilidade do Dead Code detectado ser um caso de Dead Code Estático, e não Dinâmico. Portanto é necessário que seja feito uma inspeção mais específica para classificar o Dead Code detectado em Estático ou Dinâmico Eliminação Após a detecção e classificação de Dead Codes, é necessário tratar as ocorrências identificadas. O tratamento de Dead Codes implica na sua eliminação, seja por meio de remoção do trecho de código onde ele se encontra, ou por meio de ajustes no software que torne a funcionalidade alcançável pela sua execução. A eliminação de Dead Codes Estáticos é feita pelo desenvolvedor do software, de forma manual, por meio de uma reestruturação do programa afetado, ou pelo uso de alguma ferramenta de desenvolvimento de software, que permite tanto a sua identificação, quanto à sua eliminação automática. Para decidir se deve remover uma funcionalidade não executável, detectada estaticamente, o desenvolvedor deve fazer uma análise do software e verificar se a funcionalidade identificada é requerida por algum requisito. Caso exista algum requisito que é rastreável à ocorrência de Dead Code analisada, o software deve ser reestruturado para corrigir os erros que impedem que a funcionalidade identificada seja executada. Em caso contrário, o Dead Code Estático encontrado deve ser removido do programa. Como ocorre com Dead Codes Estáticas, a eliminação de Dead Codes Dinâmicos depende essencialmente de sua rastreabilidade a algum requisito do software. Porém, isso não basta para definir como eliminar a funcionalidade não executada. Caso o Dead Code Dinâmico esteja associado a algum requisito, é necessário averiguar se os testes de cobertura foram feitos de maneira correta, ou seja, se foram previstos todos os casos de testes necessários para a correta verificação do software quanto a sua cobertura estrutural. O resultado dessa averiguação é a correção dos testes de cobertura, se eles estiverem incorretos, ou a remoção do trecho de Dead Code Dinâmico identificada, se os casos de testes não precisarem de correções. Nos casos em que o Dead Code Dinâmico não possuir relação com os requisitos já estabelecidos, deve-se fazer uma avaliação para identificar possíveis requisitos faltantes. Nesse caso, para eliminar a funcionalidade não executável, adicionam-se os requisitos necessários, que não haviam sido previamente identificados e refaz-se o processo de verificação de software. É claro que a funcionalidade não executada deve ser eliminada, se não forem descobertos requisitos faltantes Processo Integrado O fluxo completo e integrado do processo de tratamento de Dead Codes encontra-se na Figura 3. Por esse fluxo, percebe-se para o tratamento de Dead Codes são seguidos quatro passos: detecção, classificação, eliminação e registro; sendo que ao final da etapa de registro, deve-se retornar às atividades de detecção de Dead Codes até que não seja detectado mais nenhum caso. O primeiro passo, que é o de detecção, identifica de modo preliminar Dead Codes, por meio da análise estrutural do software. Essa etapa é responsável por identificar a existência de algum tipo de Dead Code, seja ele estático ou dinâmico, pois a análise estrutural de software identifica a existência de ambos os tipos. Pode ser visto que, além da etapa de detecção, no fluxo apresentado são indicados o início e fim do processo de tratamento de Dead Codes. Fica claro que o processo de tratamento de Dead Codes é iterativo e sua finalização só ocorre quando a análise de cobertura estrutural do software não detectar mais nenhum trecho não executado do programa, indicando que não foi identificada mais nenhuma ocorrência de Dead Codes. Caso a etapa de detecção indique a existência de algum trecho não percorrido do software, o processo de tratamento de Dead Codes passa para a etapa de classificação. Essa etapa envolve necessariamente a inspeção da ocorrência de Dead Codes identificada para classificá-la em estática ou dinâmica. A etapa seguinte, que é a de eliminação do Dead Code, possui dois caminhos distintos seguidos de acordo com a classificação da ocorrência identificada. Em essência, a eliminação de Dead Codes Estáticos analisa a rastreabilidade do trecho identificado com relação aos requisitos do software. Observa-se que a diferença conceitual para a eliminação de Dead Codes Estáticos é que o processo de eliminação de Dead Codes Dinâmicos põe em cheque a análise de cobertura estrutural do software realizada. Além das atividades de classificação, detecção e eliminação, foi adicionada a etapa de registro da ocorrência de Dead Code identificada. Esse registro é importante, pois representa a evidência de que o processo de verificação de software foi seguido e que contemplou as ações necessárias para a identificação e tratamento de Dead Codes. É importante ressaltar que ao fim da etapa de registro da ocorrência e tratamento do Dead Code identificado, deve-se passar novamente pela etapa de detecção. Primeiramente, 6 Serra Negra, SP - ISSN

7 isso deve ser feito para garantir que todos os casos de Dead Codes foram tratados. Além disso, é importante retomar a atividade de detecção de Dead Codes para assegurar que o seu tratamento realmente o eliminou e não resultou em outras ocorrências inesperadas. 5. CONCLUSÃO O objetivo deste trabalho é propor um processo para tratamento de Dead Codes em software embarcado de uso aeronáutico. Para isso foi feito inicialmente um estudo sobre a ocorrência de Dead Codes em software embarcado de uso aeronáutico, que identificou suas principais características, ocorrências e problemas resultantes. Além disso, foi analisada a definição de Dead Codes pela RTCA/DO-178B e a exigência que esse padrão faz a respeito da eliminação de Dead Codes em software aeronáutico. A partir do conceito de Dead Codes, tem-se, como resultado prático deste trabalho, a construção de um processo de tratamento de funcionalidades não alcançáveis. Figura 3 Processo de Tratamento de Dead Codes Esse processo abrange a detecção, classificação, eliminação e registro de código não alcançável, com o intuito de guiar o processo de verificação de software quanto ao tema deste trabalho. É importante ressaltar que a classificação citada, foi criada nesse trabalho, com o objetivo de facilitar o tratamento dos Dead Codes identificados. Ao seguir esse fluxo proposto, o desenvolvedor de software terá executado todas as atividades necessárias para o completo tratamento de Dead Codes. Pelo que é exigido pela RTCA/DO-178B, pode ser visto que essa proposta pode ser utilizada dentro do processo de verificação de software, cujos registros apresentarão as evidências necessárias para que seja demonstrado que os Dead Codes existentes foram detectados, eliminados e registrados devidamente. Por último, a construção desse processo se baseou 7 Serra Negra, SP - ISSN

8 principalmente nas ocorrências de Dead Codes citadas anteriormente, suas características e em seus problemas relacionados. Com esse processo de tratamento de Dead Codes, atendeu-se ao objetivo do trabalho que é a construção de um processo para tratamento de Dead Codes em software embarcado de uso aeronáutico. REFERENCES [1] RTCA INC. Software considerations in Airborne Systems and equipment certification, RTCA/DO-178B. Washington, D.C., p. [2] FEDERAL AVIATION ADMINISTRATION Department of Transportation. Advisory Circular B: Radio Technical Commission for Aeronautic, Inc. Document RTCA/DO-178B. Washington, D.C., p. [3] CHILENSKI, J. J.; KURTZ, J. L. Object-Oriented Technology Verification Phase 3 Report: Structural Coverage at the Source-Code and Object-Code Levels. Final p. Disponível em: < >. Acesso em: 15 mai Tratamento de Dead Codes em Software de uso Aeronáutico Renner Costa Martins, Sergio Roberto Matiello Pellegrino, Jony Santellano 8 Serra Negra, SP - ISSN