sexta-feira, 14 de setembro de 2012

A origem do termo confiabilidade apareceu em 1830, quando Babbage projetou um dos primeiros mecanismos de cálculo e, após a primeira geração de computadores, nas duas décadas seguintes. Sistemas de software estão presentes em toda parte controlando muitos dispositivos utilizados todos os dias (e.g. computador pessoal, celulares, caixas bancários, fornos industriais, aviões, foguetes), incluindo os sistemas críticos, cujo tipo de aplicação não pode tolerar um mau funcionamento, pois é aumentado drasticamente o risco às pessoas ou ainda causar grandes perdas econômicas às empresas. Muitos sistemas falham diariamente e algumas falhas mudaram a direção das pesquisas na área de tolerância a falhas. Assim, a prevenção de falhas passou a ser utilizada para incluir um controle mais rigoroso durante a fase de análise e projeto de software, estabelecendo um processo de construção de software com atividades que buscam a identificação de falhas antes da sua implementação. 
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.

Inscreva-se

Creative Commons 3.0. Tecnologia do Blogger.

Teste a Velocidade da Internet

Siga-me

Curta