sexta-feira, setembro 14, 2012
A necessidade de melhoria na qualidade software,
empregando os mecanismos de tolerância a falhas, tornou-se emergente quando
muitos estudos demonstraram que a maioria das falhas nos sistemas modernos tem
a sua origem na camada de software, o que contraria uma visão anterior, pois as
falhas em hardware foram diminuindo através dos anos como conseqüência da
qualidade dos seus componentes. Em 1993, um relatório da NRC (National Research Council) apontou que
81% do total das interrupções nos sistemas foram causadas por falhas em
software. A única alternativa eficiente seria alcançar a
confiabilidade incorporando mecanismos de tolerância a falhas na camada de
software. Assim essas técnicas, especialmente o tratamento de
exceção, foram incorporadas às necessidades de confiabilidade e detecção de falhas
na Engenharia de Software. O tratamento de exceções foi um grande tema de
debate na década de 90 na conferência USENIX C++, onde Koenig e Stroustrup apresentaram um modelo para tratamento de exceções
Orientado a Objetos. Recentemente, a tecnologia ou paradigma de Programação
Orientada a Aspectos (POA) descreve o tratamento de exceções como uma das
preocupações transversais em um programa OO e muitas pesquisas destacaram
avanços utilizando linguagens de programação orientadas a aspectos, onde a
linguagem AspectJ, uma extensão da linguagem de programação Java, aparece
freqüentemente nesses estudos.
A integração dos mecanismos de tratamento de exceção,
combinados com a tecnologia de POA levantaram diversas questões. Embora a
tecnologia possa ser utilizada para promover a modularidade e reutilização de
código no tratamento de exceção, é possível observar em
outros estudos que também pode aumentar a propensão a defeitos nos sistemas,
ocasionando uma maior evidência de exceções não capturadas. Além disso, o seu
tratamento pode ser feito de forma não intencional, quando as exceções são
lançadas e capturadas de forma inesperada por existir algum tratamento no código
de um aspecto. Outro problema grave é a transparência,
que tem sido uma propriedade controversa desde as primeiras pesquisas
envolvendo POA. A falta de consistência entre os componentes e os aspectos
tende a incorrer em implementações incorretas e os resultados revelaram um
impacto negativo dessa propriedade nas falhas dos programas implementados com
AspectJ. Outros estudos recentes, como os de Figueroa e
Tanter e Coelho et al, tentaram avaliar as vantagens e desvantagens
de se empregar a POA para modularizar o código de tratamento de exceções sob
diversas perspectivas, envolvendo as práticas de engenharia de software e
outras técnicas conhecidas, a exemplo do Design por Contrato (DbC).
Muitos autores acreditam que esses problemas poderiam
ser contornados, com a inserção das técnicas de tolerância a falhas nas fases
iniciais do desenvolvimento de softwares, pois geralmente, são empregadas
tardiamente nas fases de design. Recentemente, a necessidade de
incluir tais mecanismos nessas fases tem sido defendida como uma das principais
abordagens para garantia do alcance da confiabilidade.
Porém, um dos grandes problemas é o fato de existirem diferentes classes de
falhas, erros e defeitos a serem identificadas durante o processo de
desenvolvimento de um software. Estas classes podem representar diversos
interesses dos sistemas (e.g. persistência, log, trace) e de domínio de aplicação (e.g. regras de negócio)
dificultando a utilização das técnicas desde o início do desenvolvimento. Assim, um grande número de estudos foi conduzido
tentando compreender onde e como a tolerância a falhas pode ser integrada no
ciclo de vida do software.
Este estudo tem como objetivo:
(i) conhecer a direção das pesquisas que visam o tratamento de falhas residuais
relacionadas com as práticas de engenharia de software, (ii) como estão sendo
aplicadas e (iii) quais as limitações das abordagens mais recentes. Espera-se
investigar a evolução dessas pesquisas, principalmente, as que utilizam os mecanismos
de recuperação dos estados anterior e seguinte ao erro e através de uma
perspectiva histórica da relação entre as áreas, apresentar um juízo de valor sobre
como essas técnicas estão sendo empregadas no ciclo de vida do software.
