Limitações das Soluções

É notável nas abordagens de suporte à compreensão a ausência de referência aos produtos gerados ao longo do desenvolvimento do software. Como os autores partem sempre do pré-suposto de que a documentação inexiste ou está desatualizada, as especificações de requisitos, casos de testes e outros artefatos são ignorados na maioria das vezes. A documentação existente, ainda que desatualizada, pode ajudar na compreensão, mesmo que as informações obtidas por ela não sejam totalmente confiáveis e precisem ser verificadas. Além disso, a aproximação com técnicas e ferramentas já adotadas em outras atividades do ciclo de

vida, como na gerência de requisitos e nos testes, pode favorecer a adoção das técnicas através re-uso de conhecimento e também de artefatos existentes.

Algumas abordagens que utilizam análise dinâmica, como as de Bojic e Velasevic (2000) e Eisenbarth et al (2003), relacionam cada caso de teste a mais de uma funcionalidade ou caso de uso. Com isso é necessário selecionar um conjunto de casos de teste mais complexo, para que seja possível diferenciar as partes do código fonte que se referem a cada conceito ao se analisar os rastros gerados. Os subconjuntos dos casos de testes que se referem a cada funcionalidade devem ser diferentes entre si, ainda que possuam alguns casos de testes em comum. Apesar desta necessidade os trabalhos não citam uma forma recomendada de como criar os casos de testes para que eles formem um conjunto adequado à aplicação das técnicas e também não existe uma forma clara de se estabelecer a relação entre casos de testes e funcionalidades. É responsabilidade do mantenedor envolvido, definir os casos de testes e relaciona-los às funcionalidades da melhor forma que for possível.

4.3.1. Análise das Funcionalidades

Uma questão que a maior parte dos autores deixa em aberto é a origem dos conceitos que serão localizados no código fonte. Autores que utilizam análise estática não se fixam em definições do que são os conceitos, não se preocupando em explicar como chegar a eles, sua forma e seu conteúdo. Atribuir importância a cada conceito, organizar os relacionamentos entre eles e as demais atividades relacionadas dependem totalmente do conhecimento prévio e da capacidade do mantenedor, tanto no domínio do problema como no domínio da implementação da solução. Por outro lado, os autores que se baseiam em análise dinâmica, devido à própria natureza da solução, optam por especializar a localização de conceitos no tratamento de funcionalidades do sistema. Desta forma, os conceitos não são tão indefinidos e podem ter forma e fonte mais determinadas. Na verdade, essa escolha foi motivada pela própria natureza da análise dinâmica, pois, como visto anteriormente, não basta que o conceito seja uma funcionalidade: ela deve ser controlável pela interface do sistema.

Ambas as abordagens têm limitações importantes. A visão mais livre adotada pela análise estática não dá uma estrutura adequada aos conceitos, permitindo que eles tenham qualquer nível de abstração, dos mais abstratos aos mais técnicos e, principalmente, não definem uma forma de encaixá-los nos artefatos e documentos produzidos pelos desenvolvedores e mantenedores. Por outro lado, a visão centrada em funcionalidades adotada

nos trabalhos de análise dinâmica, acaba concentrando-se em conceitos muito triviais e de baixo nível de abstração – imprimir, salvar, mover objetos na tela. Seria interessante uma perspectiva mais ampla que estivesse mais próxima ao domínio do problema, da terminologia usada pelos usuários ao formularem requisições de mudança e que se relacionassem com as demais técnicas, artefatos e ferramentas do ciclo de vida do software.

A Tabela 7 relaciona exemplos de conceitos e funcionalidades descritos pelos autores de diferentes trabalhos. Podemos notar que o nível de abstração, de um modo geral, se concentra em pequenas atividades discretas. O uso real que uma pessoa faz do sistema, seus objetivos e possíveis processos de negócio associados a cada funcionalidade não estão representados em nenhum lugar.

Autor Conceito/Funcionalidade

Biggerstaff el al (1993) Reservar assento em vôo de companhia aérea Wilde e Casey (1996) Atualizar arquivo de log no logon e logoff

Mover um objeto na tela Apresentar estatísticas

Chen e Rajlich (2000) Tratamento de arquivos de áudio e vídeo Wong (2000) Árvores de Falha (fault trees)

Grafos de Confiabilidade

Redes de Petri Estocásticas Generalizadas Gold (2001) Salvar arquivo

Ler arquivo Eisenbarth et al (2003) Desenhar círculo

Colorir círculo Mover círculo

Tabela 7 – Exemplos de Funcionalidades em Trabalhos de Localização de Conceitos

Um conjunto de trabalhos que merece destaque neste contexto são aqueles que se basearam em casos de uso. Casos de uso é uma técnica usada para especificar requisitos funcionais de software proposta por Jacobson et al (1992) que vem sendo amplamente adotada na indústria de software. Ao utilizar uma técnica consolidada para tratar as funcionalidades, estes trabalhos se propõem a adotar uma posição diferente dos demais. Definir e organizar, relacionar casos de uso são tarefas para as quais existem métodos e ferramentas bastante conhecidas.

Mesmo assim estes trabalhos apresentaram algumas limitações, pois, ainda que tenham procurado respeitar a forma do caso de uso, mantiveram um nível de abstração muito próximo

à de funcionalidades discretas do sistema, ao invés de adotarem visões mais próximas ao domínio do problema. A Tabela 8 relaciona e exemplifica os casos de uso utilizados nestes trabalhos.

Tabela 8 – Casos de Uso utilizados em Trabalhos de Localização de Conceitos

Autor Casos de Uso

Bojic e Velasevic (2000) Imprimindo Salvando

Trabalhando com Múltiplas Janelas

Lucca et al (2000) Não há exemplos de casos de uso no trabalho publicado

El-Ramly et al (2002) Não há exemplos de casos de uso no trabalho publicado

Zhang et al (2006) Trocar valores no topo da pilha Limpar a pilha

Salah et al (2005) Salvar página Imprimir página Iniciar

Encerrar

O próximo capítulo aborda a conceituação de casos de uso e trás mais detalhes dos trabalhos de compreensão de programas que os utilizaram.