Tratamento de Falhas Residuais Durante o Design de Sistemas de Software – O Estado da Arte

Relatório Técnico de Pesquisa - Mestrado em Ciência da Computação - 25/06/2012

Instituto de Ciência e Tecnologia (ICT) - UNIFESP - São José dos Campos.

Autor: Jaguaraci Batista Silva

Tratamento de Falhas Residuais Durante o Design de

Sistemas de Software – O Estado da Arte

Jaguaraci Batista Silva

Instituto de Ciência e Tecnologia, Universidade Federal de São Paulo

Campus São José dos Campos, São Paulo-SP

[email protected]

Resumo: Para garantir a confiabilidade dos sistemas de software, várias técnicas

podem ser empregadas, cuja forma mais comum é a utilização de mecanismos de

tolerância a falhas. Eles permitem que o sistema possa evitar falhas residuais graves que

não podem ser toleradas durante a sua execução. Entretanto, essas técnicas geralmente

são empregadas tardiamente durante a construção dos softwares e a necessidade de

incluir tais mecanismos (e.g. tratamento de exceção) nas fases iniciais, tem sido

defendida por muitos pesquisadores como uma das principais abordagens para se

alcançar a confiabilidade. Neste estudo, são apresentadas diversas abordagens, que

relacionadas com as práticas de Engenharia de Software, representam o atual estado da

arte no tratamento de falhas residuais. Promovendo uma visão abrangente e aprofundada

nesse âmbito, o trabalho visa: (i) a conhecer a direção e evolução das pesquisas, (ii)

como estão sendo aplicadas e (iii) quais as suas limitações.

I. INTRODUÇÃO

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 (Avizienis et al, 2004). 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 (Avizienis, 2001). 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 (Avizienis et al, 2004).

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 consequência do aumento 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 (Florio, 2008). A

única alternativa eficiente seria alcançar a confiabilidade incorporando mecanismos de

tolerância a falhas na camada de software (Randell, 1975). 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 (Koenig e Stroustrup, 1993) 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 frequentemente 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 (Lippert e

Lopes, 2000), é 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 (Figueroa e Tanter, 2011).

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 ocasionar implementações incorretas e os resultados

revelaram um impacto negativo dessa propriedade nas falhas dos programas

implementados com AspectJ (Ferrari et al, 2010). Estudos recentes, como os de

Figueroa e Tanter (2011) e Coelho et al (2011), 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 (Castor, 2009).

Recentemente, a necessidade de se incluir tais mecanismos nessas fases tem sido

defendida como uma das principais abordagens para garantia do alcance da

confiabilidade (Romanovsky et al, 2010). 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 (Taveira et al, 2010). 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.

Desta forma, 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. Também, apresentar panorama

sobre como essas técnicas estão sendo empregadas no ciclo de vida do software.




A seção II apresenta os conceitos básicos sobre confiabilidade de forma breve e justifica

porque perseguir a confiança nos sistemas de software. A seção III descreve como os

sistemas podem alcançar dependabilidade tolerando suas falhas e apresenta as suas

principais técnicas. Na seção IV o estudo cria uma relação entre as áreas de tolerância a

falhas e engenharia de software, propondo uma visão particular de como os temas

relacionados à confiabilidade estão sendo tratados no ciclo de vida do software. Através

de uma análise das áreas de pesquisa da engenharia de software, o estudo também

evidencia nas suas práticas como as técnicas de tolerância a falhas estão sendo

empregadas na seção V. A direção das pesquisas que abordam o tratamento das falhas

residuais, que envolve o tratamento do estado anterior e seguinte ao erro na seção VI e

as situações excepcionais através das linguagens de programação na seção VII. Na

seção VIII é apresentado um senso comum sobre os estudos recentes que utilizam a

tecnologia de programação orientada a aspectos em linguagens de programação

modernas. Por fim, a conclusão e referências utilizadas estão descritas na parte final

deste estudo.

II. CONCEITOS BÁSICOS SOBRE CONFIABILIDADE

A palavra confiabilidade pode ser definida pela capacidade de um sistema fornecer um

serviço considerado confiável. Esta definição reforça a necessidade de confiança, onde

o critério para decidir se o serviço é confiável é dada pela capacidade que um sistema

possui em evitar falhas graves que não podem ser toleradas durante a sua utilização

(Laprie, 1985). 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 (Avizienis et al, 2004). Também, segundo

(Avizienis et al, 2000) e (Avizienis, 1967) os primeiros computadores já mostravam

uma preocupação com dependabilidade, empregando técnicas de redundância para

mascarar falhas de componentes menos confiáveis, controle de erros e diagnóstico de

componentes com falhas através das atividades de verificação e validação.

As técnicas para alcançar confiabilidade começaram a ganhar importância na

comunidade científica em 1967, quando pesquisadores propuseram uma integração das

práticas de detecção, diagnóstico e recuperação de falhas. Especialmente, com a

formação de comitês de pesquisa na área de Computação Tolerável a Falhas em 1970

(IEEE-CS TC) e posteriormente de Computação Confiável e Tolerável a Falhas em

1980 (IFIP WG). Notadamente, os conceitos havia se tornados emergentes e foram

publicados no livro “Dependability: Basic Concepts and Terminology”(Avizienis et al,

2000). As falhas foram então definidas em duas categorias principais: intencionais e

acidentais, onde as intencionais eram causadas por código malicioso e intrusões e as

acidentais por enganos durante as fases de concepção e uso dos sistemas.

Uma pesquisa exploratória sobre a integração das áreas de tolerância a falhas e

segurança de sistemas contra as falhas intencionais foi iniciada nas universidades de

Newcastle Upon Tyne, Toulouse e Los Angeles California, em meados da década de 80.

Logo depois, aconteceu a 1ª Conferência sobre Computação Confiável (IFIP) em 1989 e

as seguintes seis edições ajudaram a promover uma maior sinergia entre as comunidades

de confiabilidade e segurança apresentando um avanço significativo das estratégias para

tratar problemas de confidencialidade, integridade e disponibilidade, no âmbito da

confiabilidade (Avizienis et al, 2000).




Alguns anos depois, os conceitos principais envolvendo a confiabilidade de sistemas

foram dividos em três partes (Laprie, 1985) (Avizienis et al, 2004): tratamento das

ameaças, dos atributos, e os meios pelos quais a confiabilidade poderia ser alcançada

(Figura 1). Os atributos de: confiabilidade, segurança, integridade e manutenção

indicam grupos de métricas e valores em que os sistemas podem ser medidos,

comparados ou definidos para a garantia de sua confiabilidade. O atributo de

disponibilidade define qual o tempo máximo de sua indisponibilidade e indica formas

alternativas de tolerar ou não a sua interrupção. A confiabilidade define as

características de correção para continuidade a partir do ponto em que foi encontrada

uma falha. A segurança preocupa-se com as consequências desastrosas de um mau

comportamento do sistema e a integridade com a ausência de alterações impróprias e a

manutenção com a capacidade do sistema sofrer modificações e reparos para a sua

correção.

Figura1- Árvore de Confiabilidade (Avizienis, 2001).

Além dos principais conceitos de confiabilidade, em (Weber, 2002) também é possível

encontrar uma terminologia semelhante sobre os tipos de ameaças existentes (threats)

que impendem os sistemas alcançarem a confiança desejada (Figura1): o defeito, o erro

e a falha. Um defeito (failure) é definido como um desvio da especificação, que não

pode ser tolerado, mas deve ser evitado. Define-se que um sistema está em estado

errôneo, ou em erro, se o processamento posterior a partir desse estado pode levar a um

defeito. Um defeito também pode ser definido pela frustração da expectativa do cliente

quando sente incapaz de realizar algo útil com o produto (Chillarege,1996). Finalmente,

define-se falha ou falta (fault) como a causa física ou algorítmica do erro.

Em (Avizienis et al, 2004), conforme a Figura 1, são apresentadas técnicas de

prevenção, remoção, tolerância e previsão de falhas, meios os quais é possível

implementar confiabilidade nos sistemas. A prevenção de falhas pode 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 visam a

identificação de falhas antes da sua implementação. A técnica de remoção utiliza

ferramentas de verificação, validação e diagnóstico para reduzir o número de falhas

durante a fase de implementação do software. Embora sejam utilizadas nas etapas

iniciais e durante a implementação do software, essas técnicas não oferecem garantia




para um tratamento adequado as diversas falhas que podem acontecer, pois todos os

componentes envolvidos durante a execução do software também são passíveis de erros

(e.g. sistema operacional, banco de dados, middlewares, protocolos de transporte de

mensagens). A técnica de tolerância a falhas visa a garantia da correção durante a

execução do software mesmo quando hà falhas. Desse modo, é assegurado a

continuidade do sistema atendendo aos requisitos exigidos. Por fim, a prevenção de

falhas objetiva a previsão dos estados em que podem ocorrer as falhas e suas prováveis

consequências.

De forma pragmática é possível notar que se faz necessária uma combinação de todos

esses meios para assegurar a confiança em um sistema, sendo fácil compreender que as

técnicas oscilam em torno das falhas, tornando-se possível impedi-las ou eliminá-las

aplicando uma técnica adequada. Porém, as falhas remanescentes ou residuais, também

devem ser toleradas em tempo de execução (Romanovsky et al, 2010).

III. TOLERÂNCIA A FALHAS

Durante muitos anos as pesquisas na área de tolerância a falhas foram concentradas na

busca pelo desenvolvimento de componentes de hardware eficazes para lidar com as

falhas. Por algum tempo, a abordagem foi considerada como única e necessária para

atingir os atributos de disponibilidade e integridade dos dados, até Randell (Florio,

2008 (Randell, 1975)) perceber em seus estudos, que tal afirmação estava longe de ser

verdade. Segundo ele, as falhas dos componentes de hardware são apenas uma fonte de

insegurança nos sistemas de computação, o que diminui a sua importância quando o

componente melhora a sua confiabilidade, enquanto as falhas de software tornaram-se

cada vez mais relevantes com o aumento e complexidade dos sistemas de software

(Florio, 2008).

Figura 2 – Algumas das Principais Falhas e Defeitos da História da Computação (Avizienis,

2001).




Os sistemas de software estão presentes em toda parte, controlando muitos dispositivos

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 as empresas. Na verdade, muitos sistemas falham

diariamente e algumas falhas mudaram a direção das pesquisas na área de tolerância a

falhas.

Em setembro de 2001, diversos pesquisadores se reuniram em um simpósio

internacional na Universidade de Newcastle Upon Tyne (Avizienis, 2001), para

apresentar entre outros resultados, um estudo atual sobre o estado das pesquisas na área,

onde destacam-se também as principais falhas em sistemas críticos na história, através

de diversas perspectivas (Figura 2). Com base neste estudo, as principais falhas e

defeitos da histórica puderam ser analisados sob as óticas de falhas físicas dos

componentes de hardware, falhas em tempo de design dos sistemas e após a sua

implantação, quando sofrem a interação das pessoas ou outros sistemas ou dispositivos.

Também, o simpósio inclui os defeitos encontrados de forma localizada em um dado

ponto do sistema ou de forma distribuída, não só no mesmo sistema, mas em todos os

outros pontos relacionados com a execução de uma determinada funcionalidade. Além

das consequências quando alguns atributos de dependabilidade não são assegurados nos

sistemas: disponibilidade e confiabilidade, segurança no acesso e confidencialidade dos

seus dados.

Entretanto, apenas classificar as falhas e defeitos não asseguraria os atributos de

confiabilidade. Era preciso investigar novas técnicas para prevenção de defeitos,

fazendo-se necessário observar diversos pontos de vistas e classificá-los quando da sua

ocorrência nos sistemas (Figura 3) e assim tratá-los adequadamente. Com esse

pensamento, Laprie (Florio, 2008 (Laprie, 1998, 1995,1992)) realizou um estudo onde

classificou as falhas de acordo com os pontos de vista associados a sua causa:

fenomenológica (e.g. ausência de energia elétrica, raios, tornados), de natureza acidental

ou intencional seja maliciosa ou não, quando encontradas na fase de design ou uso dos

sistemas, no contexto do domínio ao qual o sistema é utilizado, podendo ser interno ou

externo aos limites do sistema e quanto a sua persistência, pois as falhas podem ser

temporárias ou permanentes.

Figura 3 – Pontos de Vista e Categoria de Falhas (Florio, 2008).




A necessidade de melhoria na qualidade software, empregando 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

(Florio, 2008). Em 1993, um relatório da NRC (National Research Council) apontou

que 81% do total de interrupções nos sistemas foram causadas por falhas em software

(Florio, 2008). Além disso, os sistemas cresciam em acessos, como hoje em dia, cada

vez mais em ambientes abertos e distribuídos, através das redes de computadores, onde

muitas vezes são construídos com alto acoplamento e baixa coesão, resultando em uma

estrutura mais propensa a defeitos (Silva e Barreto, 2008).

Devido à sua própria natureza complexa e temporal, via trocas de mensagens e cálculos

nesses ambientes, nenhuma quantidade de verificação, validação e testes pode eliminar

totalmente as falhas futuras e promover a confiança na sua consistência e

disponibilidade dos seus dados (Florio, 2008). A única alternativa eficiente, segundo

(Florino, 2008, (Randell, 1975)), seria alcançar a confiabilidade incorporando

mecanismos de tolerância a falhas na camada de software e adotar práticas de reuso

como: separação de interesses (Parnas, 1972), padrões de projeto (Alexander, 1977),

reflexão computacional (Maes, 1987), desenvolvimento baseado em componentes

(MCllroy, 1968), frameworks (Johnson e Foote, 1988), composição adaptativa (Weiser,

1993), programação orientada à aspectos (Kiczales, 1997) e utilização de middlewares

(Loughran et al, 2005). Se por um lado a utilização dessas abordagens trouxe melhoria

na qualidade dos softwares, por outro aumentou a complexidade na sua construção, e

por consequência, aumentaram também os defeitos durante o design e uso dos sistemas

de software (Silva e Barreto, 2008). Dessa forma, para não excluir a camada de software

de uma estratégia de tolerância a falhas é preciso aplicar também o princípio de

comunicação “fim-a-fim” (Florio, 2008 (Saltzer et al. 1984)):

"...rather often, functions such as reliable file transfer can be completely and

correctly implemented only with the knowledge and help of the application

standing at the endpoints of the underlying system (e.g., the communication

network)."

Pressupondo que não seja possível garantir a confiança no canal de comunicação

durante todo o percurso dos dados, a confiabilidade pode ser alcançada nos extremos

dessa comunicação. Empregando adequadamente as técnicas para tolerar falhas nas

extremidades, mantendo os sistemas de software funcionando corretamente, de acordo

com as suas especificações.

A definição de tolerância a falhas pode ser dada por:

“...um sistema é tolerante a falhas se os seus programas podem ser executados

corretamente, apesar da ocorrência de falhas..." (Avizienis, 1967).

"A tolerância a falhas visa a preservar a entrega correta de um serviço mesmo na

presença de falhas, geralmente é implementado por detecção de erros e

subsequente recuperação do sistema." (Avizienis, Randell e Laprie, 2000).

“A tolerância a falhas que visa a evitar o defeito, é realizada através da detecção

de erros e recuperação do sistema.” (Avizienis, Randell e Laprie, 2004).

Conforme as definições, a sua essência é a detecção de erros e o seu tratamento para

recuperação do sistema. Segundo (Anderson e Lee, 1981), tolerar falhas exige-se

também empregar técnicas de confinamento e avaliação do erro. De um modo geral, a

tolerância é alcançada utilizando as técnicas de detecção e recuperação de erros e

tratamento da falha (Romanovsky et al, 2010). As técnicas utilizadas na fase de




detecção podem envolver práticas de replicação, detectores de defeitos e testes

estruturais. A recuperação de erros ocorre após a detecção e envolve a troca do estado

atual incorreto para um estado livre de falhas, podendo ser feito de duas formas:

recuperação por retorno (estado anterior ao erro) e por avanço (estado posterior ao erro).

Por fim, o tratamento consiste geralmente em localizar a origem da falha, repará-la e

recuperar o funcionamento correto do sistema (Weber, 2002).

IV. TOLERÂNCIA A FALHAS E A ENGENHARIA DE SOFTWARE

Apesar de serem investigadas há bastante tempo, a utilização de técnicas de tolerância a

falhas em software, especialmente os Tratadores de Exceção (TE) (Cristian, 1982),

normalmente são empregadas tardiamente durante as fases de design nos sistemas.

Recentemente, a necessidade de incluir tais mecanismos tem sido defendida por alguns

pesquisadores como uma das principais abordagens para garantia de alcance da

confiabilidade (Romanovsky et al, 2010). Um dos grandes problemas enfrentados é que

diferentes classes de falhas, erros e defeitos podem ser identificadas durante o processo

de desenvolvimento de software. Estas classes podem representar diversos interesses

ortogonais aos sistemas (e.g. persistência, log, trace) e de domínio de aplicação (e.g.

regras de negócio) dificultando a padronização de técnicas para facilitar o uso de TE

desde o início do desenvolvimento de software (Taveira et al, 2010). Assim, um grande

número de estudos foi conduzido até agora tentando compreender onde e como a

tolerância a falhas pode ser integrada no de ciclo de vida do software.

Figura 4 – Pesquisas na Área de Engenharia de Software Relacionadas com Tolerância a Falhas.




A engenharia de software (ES) é um campo relativamente novo e emergente da ciência

da computação. Foi reconhecida na conferência da OTAN em 1968 em Garmisch,

Alemanha (Romanovsky et al, 2010). O ICSE (International Conference on Software

Enginneering) (Guezzi, 2009) e o SBES (Simpósio Brasileiro de Engenharia de

Software) (Gomes et al,2011) recentemente mostraram diversos estudos sobre o estado

da arte na área.

Neste estudo foi criada uma relação entre os conceitos de tolerâncias a falhas com os

tópicos de pesquisa do SBES. Após, foram identificados os tópicos do ICSE para

estabelecer uma relação das pesquisas nacionais e internacionais. De acordo com a

Figura 4, as pesquisas relacionadas com engenharia de software e o emprego de técnicas

de tolerância a falhas têm sua principal concentração em testes de software, além da

análise e especificação de requisitos. Isso significa que, embora a associação semântica

entre os tópicos de pesquisa e técnicas de tolerância a falhas baseadas em uma

taxonomia (Avisenis, 2004) possa haver algum erro de interpretação, pois não houve

um estudo aprofundado desta relação, esse resultado está em conformidade com

pesquisas realizadas anteriormente (Vergílio et al, 2011) (Guezzi, 2009) (Lyu et al,

2003).

Figura 5 – Tópicos de Pesquisas do SBES e ICSE Relacionados com Tolerância a Falhas.

Já a Figura 5, com base nos dados analisados em (Gomes et al, 2011) e (Guezzi, 2009),

exibe uma sincronia dos tópicos tratados no Brasil e no exterior. O que demonstra mais

uma vez, que as práticas de teste de software e análise e especificação de requisitos

também estão entre as principais linhas de pesquisa na principal e mais importante

conferência da área no mundo (ICSE). Com base na análise semântica feita

anteriormente, relacionado técnicas e práticas de cada área, é possível afirmar que as

técnicas estão inseridas no ciclo de desenvolvimento desde a fase de análise até a

manutenção dos sistemas, porém seria necessário explorar outros estudos para

comprovar a sua aplicação de fato. Vale ressaltar ainda, que não há dados que possa

relacionar o aumento ou diminuição nas linhas de pesquisa apresentadas pelo SBES.

Também, as práticas de MDD (Model-driven Development) e MDA (Model-driven

Architecture), que empregam técnicas de confiabilidade (Silva e Barreto, 2008), não

apareceram nas pesquisas. Foi possível concluir nas análises, que os tópicos

relacionados com as técnicas de confiabilidade têm despertado maior interesse dos

pesquisadores na área de engenharia de software (Guezzi, 2009) e tolerância a falhas

(Romanovsky et al, 2010). Desta forma, como base nos objetivos descritos nesta seção,

foi possível conhecer onde as técnicas estão sendo empregadas, porém, ainda se faz

necessário investigar como estão sendo aplicadas em conjunto com as práticas de

engenharia de software.

V. COMO AS TÉCNICAS PARA TOLERAR FALHAS RESIDUAIS DE SOFTWARE

ESTÃO SENDO APLICADAS?

Através de uma breve análise da relação entre pesquisas em engenharia de software

envolvendo as técnicas de tolerância a falhas (Seção IV), foi possível identificar as




seguintes áreas de pesquisa: requisitos, manutenção e reengenharia de software,

verificação e validação e design de software. Segundo (Sommerville, 2007), para

alcançar os atributos de confiabilidade usando as práticas de engenharia de software, é

necessário existir um processo de software com as atividades de inspeção e

gerenciamento de requisitos, verificação de modelos, design e inspeção de código,

análise estática, planejamento e gerenciamento testes e de configuração de versões,

onde:

Inspeção de requisitos possui a intenção de descobrir problemas com as

especificações de sistemas, porque uma alta proporção de falhas durante a

entrega de softwares é causada pelos erros de especificação. Se esses erros

puderem ser descobertos e eliminados na fase de especificação esta classe de

falha irá ser minimizada.

Gerenciamento de requisitos preocupa-se em manter o controle de mudanças e

rastreabilide de requisitos durante a concepção e construção do sistema. Muitos

erros nas entregas dos sistemas são resultados da ausência de uma gerência

efetiva das mudança de requisitos na fase de design e implementação do sistema.

Verificação de modelos envolve análise automática com uso de ferramentas

CASE para garantir a consistência interna e externa dos modelos que

representam as especificações dos sistemas. A consistência interna significa que

um único modelo é consistente, enquanto a externa que verifica a assertividade

dos diferentes modelos de acordo com a sua especificação (e.g. modelo de

estados e de objetos).

Design e inspeção de código são atividades baseadas em uma lista de verificação

de falhas comuns e possui a intenção de revelar e corrigir defeitos antes dos

testes dos sistemas.

Análise estática é uma técnica automatizada de análise de código, onde o

programa é analisado em detalhes para procurar as condições de erros em

potencial, porém sem verificar o sistema em tempo de execução.

Planejamento e gerenciamento de testes exigem um conjunto de testes para

verificação e validação do sistema, os testes podem utilizar análise dinâmica

para assegurar, em sua cobertura, a assertividade dos requisitos em relação ao

código-fonte do sistema usando uma linguagem de programação.

Gerenciamento da configuração previne erros em sistemas pela inclusão de um

componente incorreto ou a sua versão através do gerenciamento de suas versões

consonante com as mudanças de requisitos e dependências internas e externas.

Com base nesta análise inicial, serão apresentados os principais estudos de cada

campo da engenharia de software, procurando demonstrar como as técnicas de

tolerância a falhas estão sendo investigadas em conjunto com as práticas de

engenharia de software.

De acordo a visão de Sommerville (Sommerville, 2007), este estudo procurou relacionar

as pesquisas encontradas por áreas temática, por já serem bastante conhecidas pelas

principais conferências em engenharia de software (Gomes et al, 2011) (Guezzi, 2009).

V.I - Engenharia de Requisitos

Na área de requisitos, os artefatos que descrevem as necessidades do sistema são

produzidos, geralmente, durante a primeira fase de um processo de software, por isso é

importante documentar as falhas esperadas e as formas de tolerá-las. Algumas

abordagens têm sido propostas para esta finalidade, como em (Nuseibeh et al, 2000) e




outras pesquisas posteriores. Em ( Shui et al, 2005) ( Mustafiz et al, 2006) (Shui et al,

2006) os autores descrevem um processo para investigar, sistematicamente, situações

excepcionais no requisitos e fornecem uma extensão para a linguagem UML usando

diagramas de caso de uso, com a finalidade de especificar os comportamentos

excepcionais do sistema. Em (Shui et al, 2006) é descrito como os comportamentos

excepcionais podem ser especificados no nível de requisitos e como esses requisitos

conduzem a especificação e design desses componentes de acordo com um processo de

software específico para este fim. Em (Mustafiz et al, 2006) uma abordagem foi criada

para analisar a segurança e confiabilidade dos requisitos com base nos casos de uso,

onde os casos de uso normais são estendidos para tratar as situações excepcionais. De

acordo com (Shui et al, 2005), os casos de uso são anotados com sua probabilidade de

sucesso e depois seus dados são traduzidos e analisados em gráficos exibindo o grau de

confiabilidade da especificação.

V.II - Manutenção e Reengenharia

Os defeitos são uma das principais causas de falhas em software e cada vez mais são

exploradas em ataques maliciosos. A tolerância a falhas bizantinas permite que os

sistemas sejam replicados para mascarar erros do software, porém a sua implantação é

custosa (Rodrigues, 2001) e as técnicas de rejuvenescimento são alvo de muitas

pesquisas. Diversos estudos investigaram o fenômeno do envelhecimento de software,

que enfatiza a sua degradação no atendimento às suas funcionalidades ao longo do

tempo. O rejuvenescimento também é uma técnica de tolerância a falhas que combate o

envelhecimento através das práticas de reeengenharia e manutenção das partes

degradadas (Pfening et al, 1996). O conceito de rejuvenescimento pode ser visto mais

claramente, fazendo uma analogia quando se encerra um aplicativo e ao reiniciá-lo

imediatamente, o software retorna ao seu estado interno limpo, sem falhas (Kintala et al,

1995). Outras práticas também são realizadas durante as atividades de manutenção (e.g.

teste, debugging), porém, serão abordadas mais adiante nesta seção.

Várias pesquisas envolvendo rejuvenencimento de software foram apresentadas ao

longo do tempo e algumas se destacam por apresentar modelos de previsão, decisão e

custos. Em (Pfening et al, 1996) foi criado um modelo para previsão de envelhecimento.

Outro modelo foi apresentado em (Kintala et al, 1995) para analisar o rejuvenescimento

de forma constante em um ambiente de execução contínua, onde o tempo de inatividade

do software é expresso em custos. Em (Garg et al, 1998) foi criado um outro modelo

para tratamento de transações onde foram incluídas políticas de manutenção preventiva

e formas para alcançar alta disponibilidade. Uma metodologia para detecar e estimar o

envelhecimento de software foi proposta em (Moorsel et al, 1998) e (Trivedi et al, 2000)

foi proposta uma avaliação da eficácia do gerenciamento de falhas do software e como

determinar o tempo ideal para realizar as atividades de manutenção através de modelos

estocásticos. Outras técnicas de redundância também foram investigadas para dar uma

sobrevida aos sistemas de software. Em (Chandra e Chen, 2000) foram pesquisadas

técnicas genéricas de recuperação com a implementação de pares de processos e em

(Chen e Avizienis, 1996) replicações de n versões do mesmo software. Foram

apresentadas duas formas complementares de lidar com o envelhecimento software:

reinicializando-o para a um estado operacional conhecido antes de uma falha ocorrer ou

reconfigurá-lo depois de uma falha de tal modo que o software permaneça operacional

em (Yourcik e Boss, 2001).




A redução de custo envolvendo a manutenção de software motivaram outras pesquisas

para aumentar o potencial de reutilização das suas implementações, além do aumento do

tempo da disponibilidade do software. Em (Castro et al, 2003) foram criadas réplicas de

serviços que podem ser reparadas periodicamente usando o estado armazenado por

réplicas corretas, e por consequência, cada réplica pode executar implementações de

serviços distintos, o que reduz a probabilidade de falhas. Outros estudos proposeram

abordagens adaptativas e reconfiguráveis para diminuir os impactos do envelhecimento,

como em (Kalbarczyk et al, 1999) e aproximações emergentes como o GRID

computacional (Bolsica et al, 2002) e computação em nuvem (Birman et al, 2009).

V.III - Verificação e Validação

Técnicas de tolerância a falhas não são suficientes para alcançar dependabilidade, uma

vez que as falhas inesperadas não podem ser evitadas. Além disso, é importante notar

que até os sistemas tolerantes a falhas, inevitavelmente, contém falhas residuais.

Técnicas de verificação e validação (V & V) são meios eficazes para garantir que as

propriedades esperadas e as exigências das especificações sejam satisfeitas em diversos

modelos e suas respectivas implementações, ajudando na remoção de falhas dos

sistemas. Técnicas de V & V visam à garantia da correção de um sistema de software ou

pelo menos reduzir o número ou a gravidade das falhas tanto durante o desenvolvimento

quanto após a sua implantação. Existem dois tipos de métodos de verificação: os

métodos exaustivos que conduzem uma exploração exaustiva de todos os

comportamentos possíveis e não exaustivo, que explora apenas alguns dos

comportamentos possíveis. A classe não exaustiva possui técnicas de verificação de

modelos, provadores de teoremas e solucionadores de restrições. Na classe não

exaustiva existem os testes e simulações, técnicas que são amplamente utilizadas, mas

que podem facilmente deixar passar erros significativos quando verificam a

complexidade de grandes sistemas (Romanovsky et al, 2010).

Na literatura várias abordagens têm sido propostas nos últimos anos tentando aplicar

técnicas de V & V em sistemas tolerantes a falhas e este estudo apresenta como as

técnicas de verificação de modelos, provadores de teoremas e solucionadores de

restrições estão sendo empregadas para tolerar falhas.

Verificação de Modelos

Verificadores de modelos recebem como entrada um modelo formal do sistema,

normalmente concebido por meio de máquinas de estado ou de sistemas de transição de

estados, e verifica-se usando linguagens provenientes da lógica temporal, as

propriedades a serem satisfeitas (Bernardeschi et al, 2002). Todas as técnicas de

verificação de modelos são suportadas por ferramentas, o que facilita a sua aplicação, as

quais detectam a violação de uma propriedade e um contraexemplo é apresentado em

seguida, exibindo como o sistema atinge o estado incorreto quando tal propriedade é

violada (Yokogawa et al, 2001). A verificação de modelos, normalmente, requer a

especificação dos comportamentos normais, dos comportamentos de falha e

procedimentos de falha e recuperação. Assim, os sistemas tolerantes a falhas são

submetidos a uma explosão de estados (Bruns e Sutherland, 1997). Este problema

preocupa os pesquisadores e pode diminui a oportunidade de utilização da técnica, outra

preocupação é quando os sistemas de verificação não consideram os comportamentos

excepcionais dos sistemas (Romanovsky et al, 2010).




Várias abordagens têm sido propostas nos últimos anos focando na verificação de

modelos em sistemas tolerantes a falhas. Uma abordagem que pode ser utilizada para

evitar o problema de explosão estado é a técnica de verificar um modelo parcial

apresentado em (Huth e Pradhan, 2003), esta técnica tenta remover gradualmente partes

do sistema e pode ser aplicada também com sucesso para análise de segurança em

sistemas tolerantes a falhas como em (Gnesi et al, 2003). Outra técnica relevante para

verificação e validação de modelos é explorada em (Silva, 2011), a pesquisa exibe

processos, ferramentas e técnicas para a verificação e validação de modelos desde a

especificação de requisitos até o código-fonte. Utiliza-se de gerações automáticas de

modelos para evitar a incidência de erros manuais, onde foi construído um arcabouço

arquitetural que contempla a verificação e validação das propriedades dos sistemas

usando a MDA (Model-driven Architecture).

Provadores de Teoremas

Provadores de teoremas utilizam axiomas e tentam produzir novos estados usando

regras de inferência e exige de uma pessoa que se estabeleça os conceitos e seus

relacionamentos para inferir sobre a sua satisfatibilidade (Silva e Barreto, 2008).

Trabalhar com provadores de teoremas requer uma pessoa experiente com essa

abordagem, pois é comum a utilização de linguagens e simbolismos (e.g. lógica e

cálculo proposicional) (Romanovsky et al, 2010). O PVS (Prototype Verification

System) é um ambiente de verificação automática que utiliza especificações e uma

linguagem para dedução de teoremas. O estudo utilizou uma variedade de programas

construídos em linguagens funcionais e de tempo real para avaliar a tolerância a falhas

em estudos de casos (Owre et al, 1996). Outro estudo do PVS demonstrou a

preocupação com o desenvolvimento de especificações e verificações formais para

arquiteturas tolerantes a falhas, algoritmos e implementações de um modelo de uma

plataforma de computação confiável para sistemas críticos de controle de aeronaves

(Owre et al,1995). Em (Kljaich et al, 1989) é apresentado outro sistema de verificação

formal que utiliza técnicas de raciocínio lógico automatizado para validar tolerância a

falhas usando uma representação da rede de Petri, onde foi implementado como parte do

sistema, um provador de teoremas baseado em regras para manipulação de lógica de

descrições dos sistema. Outras pesquisas também utilizaram a abordagem em conjunto

com as técnicas de verificação de modelos para tolerar falhas em sistemas críticos, a

exemplo dos sistemas multi-agentes (Kummar et al, 2000) e sistemas de supervisão

industrial (Silva e Barreto, 2008) e o PVS (Owre et al, 1996).

Solucionadores de Restrições

Dada uma fórmula usando uma linguagem, expressa em uma lógica adequada, os

solucionadores de restrição tentam encontrar um modelo que satisfaça uma condição

verdadeira (Romanovsky et al, 2010). Uma dos solucionadores de restrições mais

famosos é o Alloy (Jackson, 2002), que é baseado na lógica de primeira ordem. Em

(Filho et al, 2006) os autores propuseram uma abordagem que explora a relação entre a

modelagem e a verificação formal tolerantes a falhas em sistemas distribuídos, mais

precisamente, em sistemas que usam a manipulação de exceção como mecanismo para

tolerar falhas. Outra pesquisa considerou o uso de transações atômicas coordenadas (Xu

et al, 1995), onde o mecanismo construído para tolerar falhas utiliza a manipulação de

exceção em programação concorrente e unifica as características de dois conceitos

complementares: conversação e transação. A conversação (Randell, 1975) é uma técnica

de tolerância a falhas que promove a recuperação de erros coordenada por um conjunto




de participantes, são projetados para interagir uns com os outros para prestar um serviço

específico de recuperação (e.g. concorrência cooperativa), enquanto a transação

promove tolerância aos erros por atomicidade quando da ocorrência de exceções

(Schlichting et al, 1983).

V.IV - Teste e Depuração

Teste de software e tolerância a falhas são as duas técnicas principais para o

desenvolvimento de um software confiável (Luy et al, 2003), sendo a principal técnica

de remoção de defeitos atualmente (Romanovsky et al, 2010). O teste refere-se à

verificação dinâmica do comportamento de um sistema baseado em observação de um

conjunto selecionado de execuções controladas do sistema, ou casos de teste. Embora o

teste seja largamente utilizado, quando os erros são encontrados nos casos de teste, as

falhas não podem ser corrigidas imediatamente após detectadas. Geralmente, cada falha

encontrada é depurada, por conseguinte, é possível localizar o ponto o qual ela foi

gerada. Uma das primeiras pesquisas sobre depuração de sistemas foi apresentada em

(Jacoby e Layton, 1961), 51 anos depois, diversos estudos buscam aumentar a

confiabilidade dos sistemas através da aplicação conjunta das técnicas de teste e

depuração. Em (Durelli et al, 2011) foi realizado um estudo sobre a diversidade de

aplicações da técnica de teste de software no âmbito da engenharia de software nos 25

anos de existência do Simpósio Brasileiro de Engenharia de Software (SBES).

De acordo com o estudo, é possível notar que as aplicações mais comuns, em 23 anos

de pesquisa (Figura 6), referem-se às técnicas de teste funcional, teste estrutural e teste

de mutação. Pode-se notar também que os testes estruturais são os mais pesquisados e

os autores explicam que a motivação em explorar esse tipo de teste deve-se ao fato que

quase metade dos estudos são baseados em código-fonte e a técnica já está consolidada

na academia. No entanto, o teste de mutação também tem uma presença constante e,

recentemente, a exploração de testes funcionais conquistou alguma atenção dos

pesquisadores (Durelli et al, 2011).

Figura 6 – Diversidade de Aplicações da Técnica de Teste de Software (Durelli et al, 2011).

Um grande número de modelos têm sido propostos para analisar a confiabilidade de

uma aplicação com base nos dados de falhas recolhidos durante a fase de testes, em

(Gokhale et al, 2006) propõe uma forma de incorporar as atividades de depuração

analisando um modelo de crescimento da confiabilidade de sistemas de software. Outro

estudos recentes, sobre a aplicação da técnica de depuração para aumentar a

confiabilidade de sistemas através de modelos estatísticos, podem ser vistos em (Pham

et al, 1999) e (Wong et al, 2008). Por outro lado, a utilização de modelos matemáticos




pode não ser tão realístico na prática, porque o tempo para remover uma falha detectada

depende da sua complexidade, habilidade e experiência do desenvolvedor, técnicas e

assim por diante (Huang et al, 2006). Outra pesquisa recente demonstra através de um

estudo empírico, a primeira experiência sobre o aspecto da composição e redução da

suite de testes, analisando o impacto da redução dos casos de teste sob o ponto de vista

da eficácia da técnica para localização de falhas residuais em sistemas de softwares (Yu,

Jones e Harrold, 2008).

V.V - Arquitetura e Design

Arquitetura de Software tem sido amplamente aceita como uma abordagem adequada

para melhorar a qualidade, reduzindo o tempo e o custo de produção do software

(Romanovsky et al, 2010). Uma especificação de arquitetura representa o ciclo de vida

completo de sistema e fornece, em um alto nível de abstrações, o entendimento

necessário sobre os comportamentos dos componentes e das suas interações

(conectores), além de uma descrição da estrutura estática do sistema (Perry e Wolf,

1992). Uma arquitetura de software pode ser especificada usando caixas (conceitos),

linhas (associações entre os conceitos) e notações (restrições). Algumas linguagens

formais podem ser utilizadas para descrição completa da arquitetura (ADLs) ou semi-

formais (Silva e Barreto, 2008) baseadas em notações da UML (Unified Modeling

Language) (Booch, Jacobson e Rumbaugh, 1999). No que diz respeito à especificação

de uma arquitetura tolerante a falhas, a preocupação está vigente em ambas as notações.

As abordagens propostas em (Garlan, 2003), (Filho, et al, 2003) e (Filho et al, 2005) são

exemplos de especificações formais para arquiteturas, onde são utilizadas linguagens de

descrição arquitetural tradicionais, com a finalidade de especificar explicitamente erros

e tratamentos de falhas. As abordagens propostas por (Rubira et al, 2004) e (Guelfi et al,

2004) usam a linguagem UML estendendo suas notações e criando novos perfis para

especificar os requisitos em sistemas tolerantes a falhas.

Ainda sobre a linguagem UML, diversas abordagens propõem soluções através das

transformações de modelos. O projeto ESPRIT HIDE (Bondavalli et al, 2001) visa à

criação de um ambiente integrado para a concepção e verificação de sistemas confiáveis

e modelados em UML. Em (Silva e Barreto, 2008) os autores propõem transformações

automáticas a partir das suas especificações e (Bondavalli et al, 1999) amplia

abordagem para tomada de decisões com informações relevantes sobre os modelos

derivados a partir da linguagem (e.g. taxa de ocorrência de falhas, percentual de faltas

permanentes). Uma abordagem modular e hierárquica para arquiteturas de software

confiáveis foi apresentada em (Majzik et al, 2003), onde a linguagem é usada para

descrever arquiteturas de software. Outras pesquisas sugerem processos com

refinamentos sucessivos dos modelos para melhorar a especificação das suas partes

críticas. Em (Pai e Dugan, 2002) os autores utilizam os modelos descritos em UML

usando árvores de falhas dinâmicas, onde a UML é usada como uma linguagem para

descrever a substituição do módulo e propagação de erros. Em (Ferreira et al, 2011) a

linguagem UML também foi utilizada para analisar o fluxo de exceções utilizando

diagramas de atividades.

Um modelo de especificação de uma arquitetura, geralmente, constitui apenas o

comportamento normal do sistema, como consequência, o sistema pode falhar de

maneira inesperada devido ao funcionamento anormal que não foi modelado. No âmbito

dos sistemas de críticos com requisitos estritos de funcionamento, torna-se necessário

introduzir tolerância a falhas nos níveis das abstrações propostas pela da arquitetura.




Essa ação pode melhorar a eficácia da recuperação de erros e reduzir drasticamente a

quantidade de falhas na entrega final do software após todo o seu ciclo de

desenvolvimento (Kienzle, 2008). Muitas abordagens têm sido propostas para a

melhoria da análise e modelagem de arquiteturas tolerantes a falhas, uma pesquisa

abrangente sobre esse tema está descrito em (Sozer, 2009). Falha de especificação de

arquiteturas tolerantes a falhas também podem ser encontrados em muitos trabalhos

como em: (Medvidovic e Taylor, 2000), (Medvidovic et al, 2002) e (Garlan, 2003). As

técnicas de análise para tolerar falhas da arquitetura (e.g. detecção de concorrência,

testes, verificação, simulação, desempenho) permitem que os engenheiros de software

possam avaliar a sua qualidade em relação aos seus requisitos. Algumas abordagens

foram propostas para análise de falhas, onde a maioria apresenta abordagens para

verificação da conformidade do modelo de arquitetura em relação aos requisitos para

tolerar as falhas e suas limitações (Filho et al, 2005,) e (Lemos, 2006). Outro estudo

apresentou a junção da técnica de teste para verificar arquiteturas tolerantes a falhas

(Brito et al, 2005).

A fase de projeto ou design também insere diversas informações coletadas para

especificação da arquitetura de implementação e produz diversos artefatos a serem

utilizados pelos desenvolvedores para orientar e documentar a codificação do software.

Ao lidar com sistemas tolerantes a falhas, a fase de projeto precisa de algumas

ferramentas para modelagem do domínio da aplicação, além de metodologias

específicas para conduzir as técnicas de tolerância a falhas. Em (Beder et al, 2001) e

(Garcia e Rubira, 2001) duas abordagens são apresentadas para facilitar essa prática

criando padrões de tolerância a falhas na de design do projeto de software. Em (Guelfi

et al, 2004) é exibido um estudo inicial sobre o uso da abordagem MDA, onde dada

uma especificação de uma ação coordenada atômica, é gerado automaticamente o

código na linguagem Java respectivo ao modelo especificado. Esta abordagem tem sido

sucessivamente refinada em outros trabalhos, e recentemente apresentada em

(Capozucca et al, 2006). Em (Rubira et al, 2004) uma abordagem para a especificação

de tolerância a falhas e análise durante o processo de desenvolvimento é proposto. É

considerada a abrangência da especificação de requisitos normais e excepcionais, além

de como usar essas informações para especificar os componentes durante a fase de

projeto de software e, posteriormente, a sua implementação. Em (Brito et al, 2005) é

apresentada uma estratégia semelhante, onde é adotado um processo de especificação de

componentes usando a linguagem UML para testes de software. Também é importante

mencionar que dependendo da implementação da arquitetura pode ser mais fácil ou

difícil implementar as técnicas de tolerância a falhas. Alguns estudos propuseram

padrões, porém certos padrões são mais adequados que outros. Em (Harrison e

Avgeriou, 2008) foi feita uma avaliação sobre quais padrões arquiteturais podem ajudar

a tornar os sistemas mais confiáveis.

Estilos arquiteturais e middlewares também podem promover tolerância a falhas. De

acordo com (Shaw e Clements, 1997) um estilo arquitetural é um conjunto de regras de

projeto que identificam os tipos de componentes e conectores que podem ser usados

para compor um sistema ou subsistema, juntamente com as restrições locais ou globais

sobre a forma que a composição será feita. Um middleware pode ser usado para

implementar um estilo arquitetural ou conectores, através de diversas políticas (e.g.

coordenação, persistência, segurança) (Romanovsky et al, 2010). Por isso, a tolerância a

falhas no seu suporte também necessitou ser investigada. Uma abordagem para tolerar

falhas usando a tecnologia de middleware foi idealizada em (Issarny e Banâtre, 2001).

A partir do aumento do seu uso, diversos middlewares foram pesquisados, a exemplo do




CORBA, onde muitas se referem ao tratamento de exceções como em (Issarny e

Banâtre, 2001) e (Feng, et al, 2005). Outros métodos de tolerância a falhas nos

middlewares também foram investigados a exemplo de (Bondavalli, et al, 2004). Já as

propostas utilizando estilos arquiteturais podem ser vistas em alguns trabalhos, desde a

idéia geral da abordagem em (Brito et al, 2005), o estilo iC2C (Filho et al, 2003) e um

outro baseado em componentes/conectores tolerantes a falhas (Lemos et al, 2006).

VI. TRATAMENTO DE EXCEÇÕES

John Goodenough (Goodenough, 1975) foi o primeiro a definir os conceitos envolvendo

tratamento e manipulação de exceções, suas técnicas e aplicações. Ele definiu uma

exceção como: “uma condição detectada durante a tentativa de executar alguma

operação, que são levadas ao conhecimento do solicitante para que este seja questionado

a responder, ocasionando uma condição excepcional à atenção de um tratador para

realizar o seu tratamento e/ou manipulação adequadamente”. Desde a sua primeira

aparição na década de 1970, o tratamento de exceções usando linguagens de

programação não mudou muito. Os mecanismos de manipulação das situações

excepcionais, obviamente, diferem na especificação das exceções e seus tratadores,

além da forma de prosseguir com o fluxo de controle em um sistema após a falha. No

entanto, essas diferenças são insignificantes diante dos modelos que contam com os

mesmos princípios tradicionais de recuperação de erros e o apoio a separação explícita

entre comportamentos normais e excepcionais (Garcia, Romanovsky e Issamy, 2010).

Na próxima seção serão apresentados maiores detalhes sobre a evolução do tratamento e

recuperação de erros através de mecanismos de tratamento de exceção nas linguagens

de programação.

Nos anos seguintes, diversas pesquisas foram debatidas em periódicos dedicados à

manipulação e tratamento de exceção (Romanovsky et al, 2001) e o resultado foi a

definição de uma agenda de pesquisa para os próximos anos, o que estimulou o

crescimento da comunidade científica e o interesse em questões relacionadas com o

tratamento de exceções. Infelizmente, ficou claro que muitas falhas são causadas por

soluções incompletas ou inadequadas dessas situações anormais. Dessa forma, há uma

necessidade primordial em conhecer os benefícios e desvantagens do tratamento de

exceção em projetos reais de software (Garcia, Romanovsky e Issamy, 2010) e este

estudo irá promover uma visão particular desses avanços combinados com as práticas e

técnicas emergentes da engenharia de software.

VI.I - Análise, Manutenção e Teste de Software

Técnicas de análise, como o controle de fluxo e fluxo de dados são usadas em uma

variedade de tarefas de manutenção de software. Ao serem aplicadas com suporte às

atividades de programação, estas técnicas podem explicar a causa quando da ocorrência

de exceções e a forma de construção dos seus tratadores. Muitos trabalhos apresentam

abordagens que utilizam essas técnicas a exemplo de: (Sinha e Harrold, 1998),

(Gorbenko et al 2008), (Cacho et al, 2008), (Shah et al, 2008), (Chang et al, 2002) e

(Ogasawara et al, 2006). Em (Sinha e Harrold, 1998) é feita uma análise dos efeitos das

construções de tratamento de exceção nos fluxos de controle de programas Java, onde

são criados gráficos para o controle de fluxo de métodos e também discute outras

técnicas, como teste estrutural e de regressão, que podem se beneficiar das construções

de tratadores de exceção em tarefas de manutenção. Outro trabalho possui também o

foco na análise de propagação das exceções em arquiteturas orientadas a serviços,




inclusive enfatiza que o tratamento e diagnóstico inapropriado, através desses

mecanismos, pode ser um dos principais fatores que afeta o desempenho de aplicações

que utilizam os serviços web (Gorbenko et al 2008).

Além de analisar o fluxo de exceções, outras abordagens também foram propostas para

descrever suas construções de uma perspectiva modular. O modelo EJFlow, possibilita

compreender os fluxos de exceção a partir de uma perspectiva fim-a-fim, com o foco

em um único módulo do programa. Além disso, promove uma extensão dos seus

mecanismos para a linguagem de programação AspectJ com o objetivo de promover

robustez e modularização (Cacho et al, 2008). Outra ferramenta para melhorar a

compreensão do fluxo de exceções em programas que utilizam a linguagem de

programação Java é apresentada em (Shah et al, 2008). Nesse estudo, para entender as

necessidades de visualização, foi realizado um experimento com um grupo de

desenvolvedores de software e a ferramenta ENHACE apresenta informações com base

em três perspectivas: quantitativa, fluxo de controle e contextual, fornecendo uma visão

nos níveis de pacote, classe e método com diversas abstrações. Em (Chang et al, 2002)

outra ferramenta foi construída para realizar uma análise estática que estima os

caminhos de propagação de uma exceção em programas Java. Foi construído um gráfico

de propagação a partir da análise estática, que inclui a origem das exceções, tratador e

forma de propagação. A ferramenta de visualização permite guiar os programadores na

construção dos tratadores sugerindo os locais adequados a partir do rastreamento e sua

propagação. Em (Ogasawara et al, 2006) foi apresentada uma técnica para otimizar o

fluxo de exceções durante a execução intensiva de programas Java. A técnica permite

registrar os caminhos dos fluxos exceções em um repositório enquanto apresenta

diversas estatísticas sob as várias categorias de programas. O estudo permitiu analisar os

dados para conhecer quais programas lançavam muitas exceções e os que menos

suportaram a alta sobrecarga para o seu tratamento.

Alguns anos após a clarificação das propriedades e fundamentos para o tratamento de

exceção apresentados por John Goodenough (Goodenough, 1975), diversos estudos já

demonstravam a preocupação dessa nova visão com as atividades de teste de software, a

exemplo de (Prins, 1982). O comportamento excepcional muitas vezes é mal

compreendido e testado em um programa e a presença dessas construções no bloco de

código dos tratadores introduz novos elementos estruturais, tais como controle de fluxo

de caminhos (Seção IV) em um programa. Para testar adequadamente tais programas,

estes novos elementos estruturais devem ser considerados na sua cobertura durante o

teste estrutural. Além de prover suporte a visualização do fluxo de exceções, Sinha e

Harrold (Sinha e Harrold, 2000) também discutiu outras aplicações para suporte ao teste

estrutural e seleção de testes de regressão dentro das tarefas de manutenção de software.

Em outro estudo os mesmos autores definem os critérios a serem utilizados para testar

situações excepcionais e gerar casos de testes com base na técnica de controle de fluxo.

Também a representação precisa dos fluxos de exceções nos programas, usando gráficos

para poder representar o fluxo de controle implícito das exceções e o caminho de sua

propagação nos sistemas (Jiang et al, 2007). Weimer e Buse (Weimer e Buse, 2008)

construíram uma ferramenta totalmente automatizada que estaticamente infere e

caracteriza as condições que causam uma exceção em programas que utilizam a

linguagem de programação Java. Além disso, uma metodologia para a aplicação de

critérios em testes unitários e de integração, que contém código para tratamento de

exceções pode ser visto em (Sinha e Harrold, 1999). Outras técnicas para validar a

construção de programas com tratamento explícito de exceções através de estudos




empíricos, além de (Sinha e Harrold, 2000), também serão apresentadas adiante nesta

seção.

A dificuldade em gerar dados para teste de exceções também foi explorada e na

literatura existem diversos trabalhos que apresentam técnicas para geração automática

desses dados, como em (Tracey et al, 1999). Outras abordagens buscaram facilitar o

teste de situações excepcionais utilizando análise estática (Robillard e Murphy, 2003) e

teste estrutural automático baseado nas falhas encontradas (Jiang et al, 2005). Com os

avanços das tecnologias para a Internet, outros estudos apresentam técnicas para o

tratamento de exceções em sistemas Web (Brambrilla et al, 2005) e arquitetura

orientada à serviço (Gorbenko et al 2008), além de práticas como a modelagem de

processos (Lerner et al, 2010).

VI.II - Arquitetura, Design e Especificação de Software

A separação de interesses é um dos objetivos fundamentais do tratamento de exceção, a

fim de manter separados os comportamentos normais e excepcionais de um sistema de

software. No contexto de uma linha de produto de software (SPL), essa separação de

preocupações também é importante para gerenciar as variabilidades de um software

relacionando estratégias de manipulação diferentes. Uma possibilidade de solução é a

separação desses comportamentos em linhas de produtos de software direcionando-os

para componentes específicos (Bertoncello et al, 2008). Em (Issarny e Banâtre, 2001)

foi realizada uma análise das descrições arquiteturais de um domínio de software e foi

proposta uma linguagem de descrição arquitetural para mapeamento e construção de

tratadores de exceções em arquiteturas de desenvolvimento de software. Outro

problema típico encontrado em uma arquitetura é como realizar o tratamento de

exceções independente de uma linguagem de programação. Essa solução poderia

reduzir a complexidade durante a implementação desses mecanismos e, entre outras

vantagens, aumentar o reuso dos tratadores. Um estudo apresentou uma arquitetura

genérica para incorporar o tratamento de exceções em sistemas orientados a objetos que

integra tanto o tratamento de exceções concorrentes quanto as sequenciais (Garcia et al,

2000).

Segundo (Nehmer e Reuter, 2008) os mecanismos atuais de tratamento de exceções são

insuficientes para cumprir os requisitos de confiabilidade em sistemas grandes e

complexos. Por isso, os autores apresentaram um framework para o tratamento de

exceções como uma ferramenta de suporte aos desenvolvedores. Com base na análise

do fluxo de exceção uma falha, a abordagem promove a contenção das exceções,

restringindo o seu impacto global nos sistemas. Em (Fu e Ryder, 2007) também foram

demonstrados avanços para tratar exceções em grandes sistemas, onde foi adotada uma

técnica para análise das exceções que são relançadas na arquitetura de servidores de

aplicação. Outra abordagem é pensar nos mecanismos de tratamento da exceção aliados

à técnica de replicação de dados para aumentar a confiabilidade dos sistemas. Onde a

manipulação da exceção ajuda os programadores a controlar as situações em que o fluxo

normal de execução de um programa não pode continuar, enquanto a replicação

gerencia as falhas do sistema. Entretanto a manipulação das exceções e a técnica de

replicação podem não se aplicar para as mesmas situações e, portanto, a necessidade de

um estudo aprofundado para conhecer os benefícios e limites dessa abordagem pode

ajudar na exploração benéfica dessas técnicas. Em (Dony et al, 2008) uma especificação

para execução de um sistema de tratamento de exceção para middlewares com suporte a




sistemas multi-agentes foi proposta com a combinação do tratamento de exceção e a

técnica de replicação, tornando os agentes mais confiáveis.

VI.III Estudos Empíricos

Construir componentes de forma a separar situações normais das excepcionais, além de

promover o reuso dos tratadores de exceção, foi tema de diversos estudos para avaliar

aproximações similares às apresentadas nas subseções anteriores. Muitos estudos

demonstraram métricas para tentar explicar porque a técnica de tratamento de exceção

possui determinadas limitações. As pesquisas avaliam diversos aspectos em aplicações

reais para entender como a técnica de tratamento de exceção é empregada pelos

programadores, incluindo a qualidade código de implementação em uma variedade de

linguagens de programação.

Após investigar 32 aplicações construídas usando as linguagens de programação Java e

.Net (Cabral e Marques, 2007) concluíram que as exceções não estão sendo utilizadas

corretamente como um mecanismo de recuperação de erro e os tratadores não são

suficientemente especializados para permitir a recuperação adequada. Outro estudo

avaliou a implementação de tratadores em diversas linguagens de programação

orientadas a objeto e uma taxonomia foi desenvolvida para ajudar a endereçar 10

aspectos técnicos durante a construção dos tratadores de exceção, sua representação em

tempo de design e durante a codificação dos programas de software (Garcia et al, 2001).

Segundo os autores, os programadores utilizam os tratadores de forma equivocada para

tratar outros interesses transversais (e.g. log e notificação de mensagens) dentro das

aplicações. Um estudo explorou também essa abordagem avaliando uma equipe de

programadores com o uso do modelo EJFlow (Cacho et al, 2008) o qual concluiu que a

abordagem melhorou a legibilidade e confiabilidade no código da aplicação (Cacho et

al, 2009).

A construção de tratadores de exceção usando uma linguagem de programação

orientada a aspectos (e.g. AspectJ) pode reduzir drasticamente as porções de código

relacionadas com a detecção e o tratamento de erros segundo o estudo realizado e evitar

o tratamento equivocado de outros interesses (Lippert e Lopes, 2000). Entretanto o

desenvolvimento de tais mecanismos com a tecnologia de programação orientada a

aspectos pode levar a cenários propensos a erros. Por conta dos aspectos estenderem ou

substituírem funcionalidades existentes, isso pode levar as novas exceções que não

foram previstas em tempo de design, incorrendo em formas inesperadas de execução de

um programa. Um estudo procurou avaliar o quanto os aspectos interferem no fluxo de

controle das aplicações ocasionando erros e criou um catálogo de padrões para os erros

de implementação encontrados (Coelho et al, 2008). Um novo estudo (Hoffman e

Eugster, 2008) revelou que, após reconstruir os tratadores de exceção em três aplicações

reais, a abordagem proposta pelos autores permitiu melhorar a modularização das

situações anormais utilizando pontos de junção explícitos com a linguagem AspectJ.

Neste estudo, outros avanços utilizando essa abordagem serão apresentados adiante

(Seção VIII).

VII. TRATAMENTO DE EXCEÇÕES USANDO LINGUAGENS DE

PROGRAMAÇÃO

As exceções são recursos adicionados às linguagens de programação para fornecer ao

programador a capacidade de especificar o que deve acontecer quando condições




incomuns durante a execução de um programa ocorrer, mesmo com pouca frequência.

Originalmente, em linguagens de programação, tais condições atípicas apenas eram

repassadas para controle dos sistemas operacionais que, em seguida, abortavam a

execução do programa forçosamente. Porém, quando tais condições, embora raras,

pudessem ser antecipadas, o programador poderia escrever algum código para reagir a

elas e, graciosamente, lidar com as exceções. Exceções e códigos para manipulá-las é

um mecanismo previsto pelas linguagens modernas para contornar esse problema

(Ryder, Soffa e Burnett, 2005).

A inserção de mecanismos para o tratamento exceções em linguagens de programação

está atrelada as necessidades de confiabilidade e detecção de falhas em engenharia de

software (Seção V). A linguagem precursora no suporte ao tratamento de exceções foi a

Lisp, em meados dos anos 50. Após, a PL/I, uma linguagem de programação

desenvolvida pela IBM e sua comunidade de usuários para o Sistema 360 em meados

dos anos 60, incluiu algumas facilidades para lidar com o controle de fluxo atípico em

uma linguagem de alto nível. Oferecendo suporte aos programadores para lidar com

algumas condições excepcionais, tais como: final de arquivo, overflow e corrupção dos

dados.

Em meados dos anos 1970, a confiabilidade dos sistemas era uma preocupação muito

forte entre os pesquisadores de engenharia de software e linguagens de programação.

Em março de 1977, as conferências: SIGPLAN, SIGOPS e SIGSOFT, além do

periódico “Comunications of The ACM”, apresentou uma edição especial sobre

linguagem para o design de software confiável em agosto de 1977. Assim, os

mecanismos para o tratamento de exceção, nas diversas linguagens conhecidas hoje,

foram influenciados pela pesquisa em engenharia de software (Ryder, Soffa e Burnett,

2005). No mesmo periódico, alguns meses depois, John B. Goodenough (Goodenough,

1975) apresentava diversas questões para o tratamento de exceção, classificando alguns

tipos de utilização para lidar com o domínio ou o intervalo de falha em uma operação,

indicar a importância de um resultado ou permitir monitorar uma operação (Ryder,

Soffa e Burnett, 2005).

Além das contribuições de Goodenough, neste mesmo ano, Brian Randell (Randell,

1975) descreveu sua própria construção para detecção e recuperação de erros. Ele

definiu um mecanismo estruturado chamado blocos de recuperação, que poderia ser

usado quando uma falha inesperada ocorresse. Após alguns anos, diversos estudos

investigaram a possibilidade de unir as abordagens de blocos de recuperação e

tratamento de exceção para coexistir no mesmo código a exemplo do estudo de Flaviu

Cristian (Cristian, 1982).

Perry, em seu artigo premiado no ICSE (Perry, 1989), discutiu a especificação e

manipulação das exceções como parte de um ambiente integrado de desenvolvimento

(IDE), quando sistemas de grande porte são construídos por muitos desenvolvedores. O

seu objetivo era proporcionar um IDE para grandes grupos de desenvolvedores que

trabalhavam em grandes sistemas de software. Assim, ele descreveu um projeto em que

especificações de interfaces de um módulo incluíam descrições para especificar as

exceções a serem manipuladas nos sistemas, além de estratégias para o seu tratamento.

Sua ferramenta verificava quais exceções eram tratadas de acordo com a especificação

na interface e o seu estudo demonstrou que o tratamento de exceções em linguagens de

programação no final dos anos 80 influenciou bastante a pesquisa na área de engenharia

de software no projeto de novos IDEs.




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 (Koenig e Stroustrup, 1993) apresentaram um

modelo para tratamento de exceções orientado a objetos. Os comandos são executados

dentro de um bloco try, que por sua vez, tem associado os blocos catch, que manipulam

as exceções. Este projeto foi influenciado pelo trabalho de Randall (Randall,1975),

segundo pesquisadores (Ryder, Soffa e Burnett, 2005). As exceções, possivelmente

acionadas por uma função ou operação de forma direta ou indireta, podem ser listadas

como parte da declaração da função e as violações desta especificação são tratadas em

tempo de execução, não em tempo de compilação, como na linguagem Java. Esta

decisão foi em parte devido às restrições da linguagem C, onde as funções não tinham

nenhuma construção explícita para o tratamento de exceção. Quando uma função com

uma especificação de exceção lança uma exceção que não está na sua lista, então a

função void unexpected() é chamada e sua execução geralmente é interrompida (Ryder,

Soffa e Burnett, 2005). Assim, diversas pesquisas envolvendo o tratamento de exceção

em linguagens orientadas a objetos vieram após o trabalho de Koenig e Stroustrup, a

exemplo de (Romanovsky et al, 1995), (Garcia et al, 2001), (Jiang e Xu, 2005).

Recentemente, a tecnologia de programação orientada a aspectos descreve o tratamento

de exceções como uma das preocupações transversais em um programa orientado a

objeto. Esta abordagem foi apresentada por Kiczales (Kiczales et al,1997) e expressa a

detecção e o tratamento de exceções (Lippert e Lopes, 2000) para diminuir a quantidade

de código redundante em um programa. A linguagem AspectJ permite criar crosscuts

abstratos que podem ser instanciados em muitos locais diferentes, onde a manipulação

das exceções exige o mesmo tratamento. No estudo de caso apresentado por Lippert e

Lopes, utilizando uma aplicação Java contendo 750 classes de domínio e 150 de teste,

os autores reduziram as linhas de código que continham tratamento de exceções de

10,9% para 2,9%. Isto representou uma redução significativa sobre o tamanho original

do programa e inspirou centenas de trabalhos nos últimos anos.

VIII. O TRATAMENTO DE EXCEÇÃO NO DESENVOLVIMENTO DE SOFTWARE

ORIENTADO A ASPECTOS (2009-2012)

O emprego das práticas de engenharia de software no tratamento de exceções,

principalmente em linguagens de programação modernas, tem contribuído muito para

aumentar a tolerâncias a falhas residuais de softwares e este estudo procurou conhecer

os avanços no âmbito do desenvolvimento de software orientado a aspectos nos últimos

anos.

Na última década foi percebido um aumento significativo do Desenvolvimento de

Software Orientado a Aspectos (DSOA) como uma forma de modularizar os interesses

transversais em sistemas de software, melhorando as práticas de engenharia de software

e aumentando o retorno dos investimentos neste âmbito. Vários frameworks orientados

a aspectos surgiram (e.g. AspectJ, JBoss e Spring) em grandes projetos na indústria,

onde o mais proeminente é o servidor de aplicações da IBM, o WebSphere (Rashid et

al, 2010).

Um dos maiores problemas com a técnica de POA é o fato dos aspectos estenderem ou

substituírem funcionalidades existentes durante a execução de um programa, tal ação

pode aumentar o surgimento de novas exceções, que podem ser lançadas e propagadas

de forma inesperada na pilha de execução do programa. E essa ação, diminui a

confiabilidade dos sistemas, porque as exceções não foram previstas em tempo de




design e possivelmente não serão tratadas adequadamente. Adams e Schutter

propuseram uma abordagem chamada Aspicere2. A solução fornece melhorias no

mecanismo de tratamento de exceção monitorando a propagação de erros, log, limpeza

de recursos e ainda permite substituir aspectos por outros baseados em um código de

recuperação. A Aspicere2 torna os aspectos mais robustos e tolerantes à evolução do

código da aplicação segundo os autores, porém não resolve definitivamente o problema

(Adams e Schutter, 2007).

Algumas pesquisas destacaram avanços no tratamento de exceções utilizando a

linguagem AspectJ, uma extensão da linguagem de programação Java, que é a mais

utilizada nessas pesquisas. Muitas delas estão concentradas nas práticas de análise e

teste, além de arquitetura, especificação e design de software. Por isso, o estudo fará

uma apresentação breve das principais pesquisas a partir dessa perspectiva. O que

representa os principais assuntos tratados nos últimos anos envolvendo DSOA e o

tratamento de falhas residuais, através da técnica de tratamento de exceções.

VIII.I - Análise e Teste de Software

Assegurar a confiabilidade do código que implementa o tratamento de exceção em

DSOA é uma tarefa desafiadora. O próprio teste do código já é difícil, uma vez que é

complicado lançar todas as exceções possíveis durante os experimentos e o grande

número de diferentes exceções poderia levar um sistema a infinitos casos de testes.

Além disso, observou-se que algumas propriedades da POA podem entrar em conflito

com as características dos mecanismos de tratamento de exceção, agravando os

problemas existentes (Coelho et al, 2011). Por isso, a análise e verificação do código de

tratamento de exceção estimularam diversas pesquisas.

Em uma pesquisa muito recente (Coelho et al, 2011) é apresentada uma abordagem que

utiliza uma ferramenta de análise estática chamada SAFE. O objetivo é verificar a

confiabilidade do código de tratamento de exceções em programas que utilizam a

linguagem AspectJ. O estudo avaliou a eficácia e a viabilidade da abordagem de duas

maneiras: (i) investigando se a ferramenta SAFE é suficientemente precisa para

descobrir informações do fluxo de exceção e (ii) utilizando a abordagem em três

sistemas de tamanho médio com diferentes domínios de aplicação para comparar os

resultados. O estudo ainda indica que é mais barato verificar a conformidade do

tratamento de exceção estaticamente, com base em uma especificação, que criar

diversos casos de teste para procurar todas as exceções possíveis. No entanto, um

comportamento específico dos tratadores de exceção, que é o código de recuperação

acionado após uma exceção ser capturada, funcionou corretamente, porém, essa ação

geralmente não pode ser verificada usando análise estática, já que as exceções ocorrem

em tempo de execução de um programa (Goodenough, 1975). Dessa forma, a análise

estática pode ser mais benéfica para avaliar os possíveis fluxos de exceções, assim como

em diversos estudos em que a abordagem é utilizada para verificar a assertividade dos

requisitos de um software e promover a melhoria do código através da técnica de

inspeção utilizando analisadores automáticos (Seção VI).

As informações de relacionamento entre classes de um domínio de aplicação é a base

para construção de um fluxo de exceções em linguagens orientadas a objeto, onde o

objetivo é melhorar o entendimento desses fluxos e possui diversos benefícios (e.g.

evitar código redundante, padronização do código). De acordo com os tipos de relações

entre as classes (e.g. herança, agregação e associação) a construção de um gráfico de




fluxo de controle é feito de forma incremental e essa tarefa exige um algoritmo

eficiente, pois em sistemas grandes a construção desse gráfico pode ser fastienta e

tediosa. Além de um algoritmo otimizado, é necessário melhorar a precisão para se

evitar redundâncias desses relacionamentos, o que dificultaria o entendimento dos

fluxos de exceções. Zhang et al. (Zhang, Jiang, Li e Yuan, 2009) propõem um algoritmo

usando o conceito de program slicing para construir essas relações de dependência em

softwares que utilizam classes para o tratamento de exceções, melhorando a sua

precisão em relação aos estudos anteriores (Seção VI).

Geralmente, o processo de se levantar uma exceção está intimamente relacionado com a

sua manipulação. Em sistemas complexos, o ponto em que são levantadas e o da sua

manipulação não estão necessariamente em um mesmo local (e.g. método, classe ou

pacote) (Qiu, Zhang e Lian, 2010). Em uma aplicação Java, por exemplo, uma exceção

pode fluir através de diversos métodos em um sistema, inclusive através de frameworks

e sua máquina virtual (Coelho et al, 2011). Portanto, o mecanismo para o seu tratamento

possui alguns problemas significativos quando se pretende levantar uma exceção: (i)

como identificar os manipuladores? (ii) como identificar os componentes dependentes

durante o tratamento das exceções? e (iii) como prever quais componentes serão

afetados?

Quando uma exceção é lançada, o fluxo de controle busca o código para o seu

tratamento com o objetivo de responder adequadamente e tentar a recuperação do erro,

por isso a sua propagação é necessária. Para os desenvolvedores, a propagação de uma

exceção ultrapassa a fronteira dos componentes por meio de sua pilha de chamadas.

Assim, a dificuldade para identificar em qual ponto a exceção surgiu e onde deve ser

manipulada é aumentada por causa da sua propagação. O que eleva o custo de

manutenção do software (Qiu, Zhang e Lian, 2010).

Analisando a dependência dos métodos, Qiu, Zhang e Lian associaram cada método

com os tipos de exceção, pela relação de lançamento ou captura declarada

explicitamente na sua assinatura e apresentaram um gráfico de propagação dessa

dependência. Através do código Java compilado, o algoritmo extraiu as informações de

dependência dos métodos e distinguiu quais métodos lançavam ou capturavam as

exceções, além dos seus tipos. Em seguida, efetuou a análise do caminho de propagação

das exceções e a sua estrutura de propagação em cinco softwares durante um estudo de

caso. Eles também incluíram uma análise da hierarquia das exceções e a fronteira entre

as áreas onde os métodos forneciam os mecanismos para o seu lançamento e

manipulação. Promovendo uma grande melhoria na análise do fluxo de propagação das

exceções em relação aos estudos anteriores (Seção VI).

Já que o tratamento de exceções pode garantir a modularização dos sistemas na

presença de erros, oferecendo abstrações para representar as situações errôneas nos

módulos na forma de exceções, tornou-se possível encapsular as condições de erro em

tratadores (Bernado et al, 2011). As construções de código para o tratamento de

exceções são geralmente propensas a falhas, devido, por exemplo, à falta de atenção ao

longo do ciclo de desenvolvimento do software (Bernado et al, 2011). As abordagens

baseadas em análise estática foram propostas para descobrir essas falhas, no entanto, por

conta das limitações da abordagem, combinada as características das linguagens

modernas (e.g. herança e polimorfismo) a análise estática costuma relatar muitos falsos

positivos. Assim, são necessárias etapas manuais para verificar se os caminhos

detectados durante a ocorrência de uma exceção realmente aconteceram, tornando o




processo custoso. Além disso, é vista negativamente pela limitação da abordagem

somente ser utilizada para detectar as falhas e não tratar as exceções (Bernando et al,

2011).

Com o advento das metodologias ágeis, algumas abordagens têm sido utilizadas com

sucesso no desenvolvimento de aplicações modernas e são fortemente baseadas em

automação de testes. No entanto, não enfatizam o teste dos comportamentos

excepcionais nos sistemas de forma explicita (Bernado et al, 2011). Bernardo et al

apresenta uma abordagem ágil para testar o comportamento excepcional de um sistema,

onde os desenvolvedores verificam se o caminho de propagação das exceções estão

corretos em tempo de execução. Os testes seguem uma abordagem ágil e foram

implementados a partir da extensão do framework JUnit.

Apesar da abordagem ser promissora, ainda existem outros entraves durante a adoção da

POA. Diversos estudos empíricos têm demonstrado que o DSOA promove a

modularização e estabilidade na presença de interesses transversais (e.g. tratamento de

exceções). A estabilidade no design engloba a sustentação das propriedades do sistema

e a inadvertência dos efeitos quando das suas alterações. Para avaliar as várias facetas

da estabilidade durante o design e modularização de um software, um conjunto de

métricas podem ser observadas para medir: a coesão, a propagação de mudanças,

análise da interação entre os interesses e a identificação desses efeitos na arquitetura. É

tão importante medir o impacto de uma nova tecnologia sobre a modularidade do

sistema quanto a estabilidade do seu projeto, e maior ainda, o seu impacto na robustez

do sistema. Uma nova tecnologia poderia se tornar menos útil para fins práticos, por

tornar o sistema menos resistente as falhas. Assim, a integração dos mecanismos de

tratamento de exceção, combinados com as técnicas de modularização levantam

diversas questões (Coelho et al, 2009).

Embora a POA possa ser utilizada para promover a modularidade e reutilização de

código no tratamento de exceção (Lippert e Lopes, 2000) é possível observar em outros

estudos que também pode aumentar a propensão a erros nos sistemas, ocasionando: (i)

maior evidência de exceções não capturadas, quando os aspectos atuam como

manipuladores de exceções, levando a falhas imprevisíveis no sistema e (ii) o

tratamento pode ser feito de forma não intencional, quando as exceções são lançadas por

aspectos e capturadas de forma inesperada por existir algum tratamento no seu código.

Portanto, existe uma necessidade fundamental em definir procedimentos e métricas para

avaliar o impacto das técnicas de modularização na robustez do software. Essas

métricas podem fornecer meios de avaliar se o sistema proporciona uma resposta

tolerável quando do surgimento de problemas que possam causar a sua degradação

(Coelho et al, 2009). Coelho et al apresentam um framework para avaliar a robustez dos

sistemas que utilizam a técnicas de modularização no tratamento de exceções através de

análise estática e dinâmica, incluindo novas métricas que não foram consideradas em

estudos empíricos anteriores. Além do conjunto de métricas, foi definida uma

abordagem para suas medições utilizando a linguagem AspectJ.

A transparência (obliviousness) é o ato ou o efeito de deixar algo transparente, no

sentido de poder ser esquecido ou passar despercebido. Nesse contexto, a transparência

permite que os componentes não necessitem ser preparados para receber qualquer

melhoria proporcionada pelos aspectos (Chavez, 2004). A transparência tem sido uma

propriedade controversa, desde as primeiras pesquisas envolvendo programação

orientada a aspectos. A falta de consistência entre os componentes e os aspectos tende a




incorrer em implementações incorretas. Alguns estudos contradizem a intuição comum

que a utilização dos pontos de junção é a principal fonte de defeitos, onde os outros

mecanismos atualmente disponíveis em AspectJ (e.g. pontos de junção, adendos e

declarações inter-tipo) também são propensos a falhas. Os mecanismos internos da POA

demonstram ter uma boa indicação de falhas quando são considerados conjuntos de

módulos dentro de cada interesse da aplicação separadamente. Neste caso, o número de

falhas associadas a um interesse pode ser diretamente proporcional ao número de

mecanismos utilizados para implementá-la. Assim, os resultados revelaram um impacto

negativo da propriedade de transparência nas falhas dos programas implementados com

AspectJ (Ferrari et al, 2010). Entretanto, abordagens recentes e outras linguagens com

suporte à programação orientada a aspectos podem ajudar a amenizar o problema da

transparência. Alguns exemplos são as Interfaces de Programação de Interesses (XPIs) e

Pontos de Junção Explícitos (EJPs) (Hoffman e Eugster, 2008). Embora elas reduzam a

transparência entre os módulos do sistema, essas abordagens ajudam a melhorar a

compreensão, tornando a interação aspecto-componente mais explícita (Ferrari et al,

2010).

Quando uma situação anormal ocorre, uma exceção é lançada e, em seguida, se propaga

de forma dinâmica através da pilha de chamadas em busca de um manipulador

adequado. O manipulador é uma parte do código que é executada ao receber uma

exceção como parâmetro. Se um manipulador não for encontrado, a exceção não é

capturada, e geralmente, a execução do programa é abortada. Exceções tratadas usando

um aspecto podem ser inadvertidamente manipuladas. Por outro lado, as exceções

podem ser abrangidas pelos manipuladores contidos em outros aspectos.

1 class A { 2 public void foo() { 3 Integer configValue; 4 try { configValue = getConfiguration(); 5 } catch(Exception ex) { configValue = DEFAULT}} 6 } 7 aspect Logging { 8 Object around() : call(Integer getConfiguration()) { 9 logger.append("Calling getConfiguration’’); // FileNotFoundException 10 return proceed();} 11 }

Listagem 1 – Captura de uma Exceção através de um Aspecto (Figueroa e Tanter, 2011).

Considerando o código de implementação de um manipulador em AspectJ (Listagem 1),

ao instanciar a classe foo e executar o método getConfiguration() para definir um valor

de configuração (ConfigValue), em caso de falha, um valor padrão será utilizado. O

aspecto registra as informações durante a execução do método getConfiguration(), se o

objeto logger não encontrar o arquivo de log ocorrerá uma falha e esta será lançada por

meio de uma exceção do tipo FileNotFoundException, que é interceptada pelo

manipulador implementado em AspectJ. Assim, o valor padrão é usado porque o

aspecto falhou, mesmo nos casos em que o método getConfiguration() retornaria o valor

corretamente (Figueroa e Tanter, 2011).

Esta situação ocorre porque o mecanismo de tratamento de exceção mescla os aspectos,

os manipuladores e as exceções em uma única estrutura plana. Este problema é

conhecido por conflation, uma generalização do problema de vinculação tardia (Late

Binding Handler Pattern) descrito por (Coelho et al, 2008) como:




"O problema acontece quando um aspecto é criado para lidar com uma

exceção, mas as interceptações do aspecto em um ponto, durante a execução do

programa em que a exceção foi capturada, já estava atrelado a um manipulador

na pilha de chamada do método que liga o sinalizador da exceção ao

manipulador construído no aspecto".

A fusão entre os aspectos, as exceções e seus manipuladores pode, inadvertidamente,

desencadear a execução de manipuladores não intencionais, mudando o comportamento

esperado do programa, onde as exceções são capturadas acidentalmente pelos aspectos

através dos seus tratadores ou vice-versa. Assim, os programadores não podem ter

certeza da interação desejada entre as exceções, os aspectos e seus tratadores. Em

(Figueroa e Tanter, 2011) foi proposta uma linguagem semântica orientada a aspectos

que permite especificar os níveis execução de um tratador de exceção, demonstrando ser

uma possível solução para o problema de conflation. Por padrão, a linguagem assegura

que não haja nenhuma interação entre os aspectos, as exceções e os seus tratadores e

permite flexibilizar uma interação específica entre eles quando necessário.

Outros estudos recentes tentaram avaliar os benefícios e desvantagens de se empregar a

POA para modularizar o código de tratamento de exceções. Apesar dos muitos estudos

interessantes, eles não atingiram um consenso no tocante ao impacto da POA no reuso

de tratadores de exceções. Inclusive, em alguns casos, os resultados desses estudos estão

em contradição direta (Taveira et al, 2009).

Castor et al. (Castor et al, 2009) apresentam um estudo aprofundado sobre a adequação

da linguagem AspectJ para fins de modularização e reuso do código de tratamento de

exceção. O estudo consistiu em refatorar o código responsável pelo tratamento de erros

em aplicações existentes para os manipuladores de exceção criados em AspectJ.

Realizou uma análise quantitativa de 5 sistemas, sendo 4 orientados a objeto e 1

orientado a aspecto, utilizando 4 atributos de qualidade: separação de interesses,

acoplamento, coesão e consistência. O estudo também investigou outras questões sob

diversas perspectivas dos sistemas refatorados, incluindo: (i) de que forma os aspectos

podem ser reutilizados para tratamento de erros, (ii) os efeitos benéficos e prejudiciais

dos aspectos e (iii) a escalabilidade da POA no apoio a modularização do tratamento de

exceção na presença de outros aspectos. A conclusão geral do trabalho (Castor et al,

2009) é que a POA não corrige design ruins, em outras palavras, sistemas orientados a

objetos onde o código de tratamento de exceção já está bem estruturado, a POA melhora

a estrutura por separar as situações normais das excepcionais do sistema. No entanto,

para sistemas complexos ou com o código de tratamento de exceção mal-estruturados, a

POA piora a qualidade do sistema.

O estudo também indica que a melhor abordagem para extração das situações anormais

a serem implementadas nos aspectos, é pensar nessa construção desde o início, em todas

as fases do desenvolvimento de software. Quando esta situação não é possível, por

exemplo, em sistemas que já foram construídos, o trabalho fornece uma orientação para

melhoria do design, tornado o processo de transformação do código de tratamento de

exceção em aspectos mais simples. Também, apresenta um catálogo que abrange uma

gama de cenários que pode ser utilizado por programadores iniciantes ou experientes no

DSOA (Castor et al, 2009).

Nesse âmbito, a avaliação do impacto da modularização das situações excepcionais,

usando tratamento de exceção em sete sistemas com a linguagem AspectJ, também foi




tema de outra pesquisa recente. A tarefa iniciou com a modularização interna dos

aspectos em cada aplicação e, em seguida, tentou reutilizar o código para manipular as

exceções entre as sete aplicações. Os resultados do estudo indicam que apenas alguns

aspectos puderam ser reutilizados, embora o nível alcançado de reuso fosse além do

esperado pelos autores e muito diferente dos estudos realizados pelo grupo em

experimentos anteriores (Taveira et al, 2009).

VIII.II - Arquitetura, Especificação e Design de Software

O desafio no tratamento de situações excepcionais aumenta constantemente com um

número crescente de dispositivos conectados nas redes de computadores e os erros estão

presentes em todas as camadas, desde os hardwares em plataformas distribuídas até os

componentes de software (Mercadal et al, 2010). Os componentes são geralmente

construídos por terceiros e eles são independentes uns dos os outros, onde os

fornecedores dos componentes não podem prever todos os usos possíveis de um

componente. Assim, não se pode tratar todas as exceções que o componente irá gerar

em diferentes sistemas (Huang et al, 2011). Além disso, muitos sistemas são baseados

em componentes e geralmente executados em algum middleware, que encapsulam

diversas soluções para resolver problemas comuns no desenvolvimento de software e na

sua operação (e.g. gerenciamento do ciclo de vida do componente, controle de

concorrência, interoperabilidade e segurança).

Uma vez que o middleware já é muito complexo, é também susceptível a causar

exceções e essas exceções normalmente são lançadas como erros de sistema e incapaz

de serem tratadas pela aplicação (Huang et al, 2011). Também por conta da necessidade

de mudanças nos sistemas e nos componentes de software, o código que implementada

o tratamento de exceção, que está embutido nos componentes, precisa ser revisto e

melhorado a cada mudança, além de ser abrangente e modular aos pontos de vista da

arquitetura, proporcionando maior reuso dos componentes (Mercadal et al, 2010).

Os estilos arquitetônicos também permitem a reutilização das arquiteturas e aplicam

com sucesso padrões de design para uma classe particular de sistemas. O problema é o

fato dos conjuntos de junção (pointcuts) serem tipicamente usado pelas LDA-OA atuais

para selecionar os pontos de junção com base nos nomes dos elementos arquitetônicos,

expondo a LDA a fragilidade dos conjuntos de junção (Greenwood et al, 2007) (Kellens

et al, 2006) e problemas de reutilização (Chavez et al, 2009). Tratamento de exceção

tem sido amplamente referido na literatura como uma preocupação transversal em

sistemas, seguindo os diferentes tipos de design (e.g. arquiteturas em camadas e MVC).

A manipulação do erro é amplamente reconhecida como um problema de design e tende

a afetar quase todos os módulos essenciais dos sistemas. Desse modo, é natural o

entendimento sobre as exceções serem de natureza arquitetônica e, neste contexto,

estarão sempre associadas aos componentes e suas interfaces.

Por definição, uma exceção é de natureza arquitetônica se levantada dentro de um

componente da arquitetura, mas não manipulada pelo mesmo que a criou (Chavez et al,

2009). Em (Chaves et al, 2009) é proposto um modelo de estilo arquitetural baseado em

pontos de junção para fornecer uma linguagem de conjuntos de junção com base na

semântica dos estilos arquitetônicos. Estilo é baseado em um modelo de pontos de




junção e a abordagem proposta para composição é independente de linguagem e pode

ser adaptável a LDA diferentes para definir um estilo de comportamento específico.

Em outro contexto, uma linha de produtos de software (LPS) visa a melhorar o

desenvolvimento e a eficiência durante a construção de uma família de sistemas de

software de um determinado domínio de aplicação. O conceito promove a reutilização

em larga escala, através da arquitetura de linhas de produtos (ALP). Assim, é comum a

existência de uma variedade de produtos similares em termos dos seus elementos

arquitetônicos. A combinação de uma LPS e Desenvolvimento Baseado em

Componentes (DBC) é uma técnica bem conhecida para conceber produtos de forma

rápida e eficaz, a partir de um conjunto de artefatos reutilizáveis (Tizzei et al, 2011).

Nesse aspecto, o DSOA é uma técnica que apoia a modularidade e permite implementar

interesses transversais, porém existem muitas evidências que o uso dos aspectos pode

levar a instabilidades nas aplicações e alguns estudos têm combinando DSOA e LPS

para estruturar a construção de artefatos através dos aspectos. Por isso é necessário

investigar os impactos negativos e positivos que a utilização dos componentes e os

aspectos promovem na estabilidade e no design da arquitetura.

Em (Dantas et al, 2010) foi criado um modelo de benchmark para LPS que utilizam

POA, o que permite caracterizar, quantificar e comparar a estabilidade em LPS

promovido pelo DSOA e seus mecanismos de variabilidade convencionais. Em um

estudo recente, foi avaliada a estabilidade de uma ALP de três formas: (i) uma aplicação

construída utilizando uma abordagem híbrida com os aspectos e componentes e as

outras baseadas em (ii) componentes, (iii) totalmente orientada a objetos e a última (iv)

totalmente orientada a aspectos, onde cada implementação possuía oito versões

funcionalmente equivalentes. Foi utilizado um conjunto de métricas para avaliar o

impacto das mudanças e modularidade para medir a estabilidade da arquitetura. O

experimento indicou que a abordagem híbrida foi a mais estável na maioria das oito

versões (Tizzei et al, 2011).

Outras técnicas buscaram a verificação das propriedades especificas do domínio a partir

do DSOA. O Design por Contrato (DbC) é uma técnica para desenvolver e melhorar a

correção funcional dos sistemas de software por meio da definição de contratos entre as

classes clientes e seus fornecedores. Os contratos são aplicados durante a execução dos

sistemas e se um deles é violado, ocorre um erro na aplicação. Runtime Assertations

Checkers (RACs), que é uma técnica combinada a DbC, impõe a verificação desses

contratos em tempo de execução da aplicação. Apesar de amplamente utilizada, os

estudos mostraram que as características dos mecanismos de tratamento de exceções em

linguagens modernas, podem descartar as violações de contrato detectadas pelos RACs.

Como resultado, a violação de um contrato não pode ser refletida em um erro durante a

execução de um sistema, inviabilizando a abordagem de DbC.

Um estudo recente apresenta uma técnica de recuperação de erros usando RACs que

adentra tais limitações. A técnica se baseia na POA e objetiva a extensão das

funcionalidades dos RACs existentes que interrompem as violações de contrato no

momento em que seriam descartadas. A técnica de recuperação é baseada em 5 RACs

baseados em Java: JML/jml, JML/ajml, JContractor, CEAP e Jose. Os resultados

preliminares demonstraram que a abordagem pode realmente impedir as violações

contratuais de serem descartadas, independentemente das características do código de

manipulação de exceção do aplicativo (Rebêlo et al, 2011).




IX. CONCLUSÃO

Sistemas de software estão presentes em toda parte controlando muitos dispositivos

utilizados todos os dias, incluindo os sistemas críticos, cujo tipo de aplicação não pode

tolerar um mau funcionamento. Muitos sistemas falham diariamente e algumas falhas

mudaram a direção das pesquisas na área de tolerância a falhas (Avizienis, 2001). Em

1993, um relatório da NRC (National Research Council) apontou que 81% do total de

interrupções nos sistemas foram causadas por falhas em software e a única alternativa

eficiente seria alcançar a confiabilidade incorporando os mecanismos de tolerância a

falhas nessa camada (Florio, 2008). A maioria das abordagens, que visam eliminar as

falhas residuais durante o desenvolvimento de softwares modernos, está relacionada

com as práticas de engenharia de software. O que significa que as técnicas de tolerância

as falhas estão sendo utilizadas em todo o ciclo de vida do software. Desse modo, essas

técnicas, especialmente o tratamento de exceção, podem responder as necessidades

atuais de confiabilidade dos sistemas de softwares. Pois o tratamento de exceções, que

foi muito debatido na década de 90 (Koenig e Stroustrup, 1993) ainda é acreditado por

muitos pesquisadores como uma das principais abordagens para se alcançar a

confiabilidade (Romanovsky et al, 2010).

Muitas linguagens possuem o suporte ao modelo de tratamento de erros proposto por

Koenig e Stroustrup durante muitas décadas e não houve mudanças desde o modelo

criado por eles na década de 90 (Garcia, Romanovsky e Issamy, 2010). Nos últimos

anos, a integração desses mecanismos combinados com a tecnologia de Programação

Orientada a Aspectos (POA) despertaram o interesse da comunidade acadêmica e

levantaram diversas questões. Embora o paradigma seja utilizado para promover a

modularidade e reutilização de código é possível observar em diversos estudos que o

seu uso pode tornar os sistemas mais propensos a falhas. Por intermédio de estudos

recentes, este trabalho discerniu sobre as reais vantagens e desvantagens no emprego de

uma LOA dentro desse contexto, incluindo o tratamento das situações excepcionais nos

sistemas de software. Por limitações da linguagem AspectJ, os estudos contradizem uns

aos outros, levando até mesmo ao descrédito no alcance do reuso e a modularização

junto com a estabilidade do software, da arquitetura e dos seus componentes.

Este trabalho considera que os estudos recentes na área de tratamento de exceções que

utilizam uma LOA, por estar no limiar das suas próprias técnicas, pouco exploraram

dentre tantas técnicas existentes e já consolidadas pela academia (Seções IV e V), a

exemplo das práticas de Verificação e Validação de Modelos e Teste de Software

Baseado em Modelos. Pesquisas emergentes como as de Silva e Barreto (2008) e

Aichernig e Jobstl (2012) são promissoras por contornar alguns problemas,

especialmente, a criação e correção manual de classes de falhas que tratam as situações

excepcionais, além de permitir maior abstração na criação dessas classes. Tais

vantagens aumentariam a confiabilidade, o reuso e a modularização desde as definições

arquiteturais até o código da aplicação. Por isso, o próximo passo desse projeto será a

realização de um estudo para conhecer quais as vantagens e limitações dessas técnicas,

através da condução de um experimento. Após, a criação de uma plataforma para

derivação de casos de testes, onde os testes serão gerados considerando os modelos de

classes de falhas e de domínio de aplicação.




REFERÊNCIAS

[1] Adams, B., Schutter, K. D.. (2007) "An Aspect for Idiom-based Exception

Handling". Proceedings of the International Workshop on Software Engineering

Properties of Languages and Aspect Technologies (SPLAT’07). March 12-13,

Vancouver, British Columbia, Canada.

[2] Aichernig, B. K., Jobstl, E.. (2012) "Towards Symbolic Model-Based Mutation

Testing: Combining Reachability and Refinement Checking". Proceedings of the

Seventh Workshop on Model-Based Testing (MBT 2012). European Joint

Conference on Theory & Practice of Software (ETAPS 2012), Tallinn.

[3] Anderson, T.; LEE, P. A.. (1981) "Fault Tolerance Principles and Practice",

Englewood Cliffs, Prentice-Hall.

[4] Alexander, C.. (1977), “A Pattern Language”, Oxford University Press, ISBN:

0195019199.

[5] Avizienis, A., Laprie, J.C., Randell, B., Landwehr, C.. (2004) “Basic Concepts and

Taxonomy of Dependable and Secure Computing”, IEEE Transactions on

Dependable and Secure Computing, Vol 1, No 1, Janeiro.

[6] Avizienis, A., Laprie, J.C., Randell, B., Landwehr, C.. (2000) “Fundamental

Concepts of Dependability”, III Information Survivability Workshop -- ISW-2000,

Massachusetts.

[7] Avizienis, A., Chen, L.. (1996) "N-Version Programming: A Fault-Tolerance

Approach to Reliability of Software Operation". IEEE Proceedings of FTCS-25,

Volume III.

[8] Beder, D. M., Romanovsky, A., Randell, B., Rubira, C. M. F.. (2001) “On

Applying Coordinated Atomic Actions and Dependable Software Architectures in

Developing Complex Systems”. Proceedings of the 4th IEEE International

Symposium on Object-Oriented Real-time Distributed Computing (ISORC’01),

Magdeburg.

[9] Bernardeschi, C., Fantechi, A., Gnesi, S.. (2002) "Model Checking Fault Tolerant

Systems". Software Testing Verification and Reliability, Vol. 12, Issue 4, pages

251–275, Dezembro.

[10] Bernardo, R. D., Jr, R. S., Castor, F., Coelho, R., Cacho, N., Soares, S.. (2011)

"Agile Testing of Exceptional Behavior". Proceedings of the 25th Brazilian

Symposium on Software Engineering (SBES'11). IEEE Computer Society.

[11] Bertoncello, I. A., Brito, P. H. S., Dias, M. O., Rubira, C. M. F.. (2008) "Explicit

Exception Handling Variability in Component-based Product Line Architectures".

Proceeegins of the International Workshop on Exception Handling (WEH’08).

November, Atlanta, Georgia.

[12] Birman, K., Chockler, G., Renesse, R. V.. (2009) "Towards A Cloud Computing

Research Agenda". LADIS Workshop on Large Scale Distributed Systems.

[13] Booch, G., Jacobson, I., Rumbaugh, J. (1999). “Unified Modeling Language –

User’s Guide”. Addison-Wesley, 1999.

[14] Bolsica, G. et al..(2002) "MPICH-V: Toward a Scalable Fault Tolerance MPI for

Volatile Nodes" Proceedings of the IEEE/ACM SC2002 Conference.

[15] Bondavalli, A., Majzik, I., Mura, I.. (1999) “Automatic Dependability Analysis

for Supporting Design Decisions in UML”, Proceedings of the 4th IEEE

International Symposium on High Assurance Systems Engineering, IEEE Computer

Society.

[16] Bondavalli, A., Cin, M. D., Latella, D., Majzik, I., Pataricza, A., Savoia, G..

(2001) “Dependability Analysis in the Early Phases of UML-based System Design”.




International Journal of Computer Systems Science & Engineering, vol. 16, nº 5,

pags.265-275.

[17] Bondavalli, A., Chiaradonna, S., Cotroneo, D., Romano, L.. (2004) “Effective

fault treatment for improving the dependability of COTS and Legacy-based

Applications”. IEEE Transactions on Dependable and Secure Computing, vol.1, nº

4.

[18] Brambilla, M., Ceri, S., Comai, S., Tziviskou, C..(2005) "Exception Handling in

Workflow-Driven Web Applications".Proceedings of the International World Wide

Web Conference Committee (IW3C2).ACM 1-59593-046-9/05/0005, Chiba, Japan.

[19] Brito, P. H. S., Rocha, C. R., Filho, F. C., Martins, E., Rubira, C. M. F.. (2005)

“A Method for Modeling and Testing Exceptions in Component-based Software

Development”. Proceedings of the Latin-American Symposium on Dependable

Computing (LADC 2005).

[20] Bruns, G., Sutherland, I. (1997) "Model Checking and Fault tolerance".

Proceedings of the 6th International Conference on Algebraic Methodology and

Software Technology, Springer-Verlag, London.

[21] Cabral, B., Marques, P.. (2007) "Exception Handling: A Field Study in Java and

.Net". Proceedings of the European Object-Oriented Programming (ECOOP), pp.

151-17.

[22] Cacho, N., Filho, F. C., Garcia, A., Figueiredo, E.. (2008) "EJFlow: Taming

Exceptional Control Flows in Aspect-Oriented Programming". Proceedings of

Aspect-Oriented Software Development (AOSD), ACM 978-1-60558-044-

9/08/0003, Brussels, Belgium.

[23] Cacho, N., Dantas, F., Garcia, A., Castor, F.. (2009) "Exception Flows made

Explicit: An Exploratory Study". Proceedings of the Brazilian simposium on

Software Engineering (SBES'09). IEEE Computer Society.

[24] Capozucca, A., Guelfi, N., Pelliccione, P. , Romanovsky, A., Zorzo, A.. (2006)

“CAADRIP: A Framework for Implementing Coordinated Atomic Actions”.

Proceedings of the 17th IEEE International Symposium on Software Reliability

Engineering (ISSRE 2006), Novembro, Raleigh, North Carolina.

[25] Castor, F., Cacho, N., Figueiredo, E., Garcia, A., Rubira, C. M. F., Amorim, J.

S., Silva, H.. (2009) "On the Modularization and Reuse of Exception Handling with

Aspects". Software Practice and Experience, Vol. 39, Wiley InterScience, pp. 1377-

1417.

[26] Castro, M., Rodrigues, R., Liskov, B.. (2003) "BASE: Using Abstraction to

Improve Fault Tolerance".ACM Transactions on computer Systems, Vol. 21, Nº 3,

Agosto.

[27] Chandra, S., Chen, P. M.. (2000) "Whither Generic Recovery from Application

Faults? A Fault Study using Open-source Software". Proceedings of the

International Conference on Dependable Systems and Networks (DSN 2000).

[28] Chang, B. M., Her, S. H., Jo, J. W.. (2002) "Visualization of Exception

Propagation for Java using Static Analysis". Proceedings of the Second IEEE

International Workshop on Source Code Analysis and Manipulation (SCAM’02).

IEEE computer Society.

[29] Chavez, C. V. G. (2004). “Um Enfoque Baseado em Modelos para o Design

Orientado a Aspectos”. Tese de doutorado, Pontifícia Universidade Católica do Rio

de Janeiro, p.73-90.

[30] Chavez, C., Oliveira, M., Garcia, A., Sant'Anna, C., Batista, T., Rashid, A..

(2009) "Composing Architectural Aspects Based on Style Semantics". Proceedings




of the 8th International Conference on Aspect-Oriented Software Development

(AOSD'09). Charlottesville, Virgina.

[31] Chillarege, R.. (1996) “What is Software Failure?”. IEEE Transactions on

Reliability, Vol. 45, No. 3, September.

[32] Coelho, R., Rashid, A., Garcia, A., Ferrari, F., Cacho, N., Kulesza, U., Staa, A.

V., Lucena, C.. (2008) "Assessing the Impact of Aspects on Exception Flows: An

Exploratory Study". Proceedings of the European Object-Oriented Programming

(ECOOP).

[33] Coelho, R., Lemos, O. A. L., Ferrari, F. C., Masiero, P. C., Staa, A. V..(2009)

"On the Robustness Assessment of Aspect-Oriented Programs". Proceedings of the

3rd Workshop on Assessment of Contemporary Modularization Techniques

(ACoM.09).

[34] Coelho, R., Staa, A. V., Kulesza, U., Rashid, A., Lucena, A.. (2011) "Unveiling

and Taming Liabilities of Aspects in the Presence of Exception: A Statict Analysis

Based Approach". Information Sciences, vol. 181, nº (2011)2700-2720, Elsevier, pp

2700-2720.

[35] Cristian, F.. (1982) "Exception Handling and Software Fault Tolerance". IEEE

Transactions on Computers, Vol. C-31, Nº. 6, Junho.

[36] Dantas, F., Figueiredo, E., Garcia, A., Sant'Anna, C., Kulesza, U., Cacho, N.,

Soares, S., Batista, T., Coelho, R., Alférez, M., Moreira, A., Pimentel, A., Araujo,

J.. (2010) "Benchmarking Stability of Aspects-Oriented Product-Line

Decompositions".Proceeedings of the 4th International Workshop on Assessment of

Contemporary Modularization Techniques (ACoM.10), SPLC 2010, South Korea,

September.

[37] Dony, C. Urtado, C., Tibermacine, C., Vauttier, S.. (2008) "Specification of an

Exception Handling System for a Recplicated Agent Environment". Proceeegins of

the International Workshop on Exception Handling (WEH’08). November, Atlanta,

Georgia.

[38] Durelli, V. H. S., Araujo, R. F., Silva, M. A. G., Oliveira, R. A. P., Maldonado,

J. C., Delamaro, M. E.. (2011) "What a Long, Strange Trip It’s Beeny: Past, Present,

and Future Perspectives on Software Testing Research". Proceedings of the 25th

Brazilian Symposium on Software Engineering (SBES 2011).

[39] Feng, Y., Huang, G., Zhu Y., Mei, H.. (2005) “Exception Handling in

Component Composition with the Support of Middleware”, Proceedings of the 5th

International Workshop on Software Engineering and Middleware (SEM 2005).

[40] Ferrari, F., Burrows, R. Lemos, O., Garcia, A., Figueiredo, E., Cacho, N., Lopes,

F., Temudo, N., Silva, L., Soares, S., Rashid, A., Masiero, P., Batista, T.

Maldonado, J.. (2010) "An Exploratory Study of Fault-Proneness in Evolving

Aspect-Oriented Programs". Proceedings of the International Conference on

Software Engineering (ICSE'10). Cape Town, South Africa.

[41] Ferreira, J., Martins, E., Brito, P. H. S., Rubira, C. M. F.. (2011) "Validation of

Exception Handling in the Development of Dependable Componente-based

Software Systems". Proceedings of the Latin-American Symposium on Dependable

Computing (LADC 2011).

[42] Figueroa, I., Tanter, E.. (2011) "A Semantics for Execution Levels with

Exceptions". Proceedings of the International Workshop on Foundations of Aspect-

Oriented Languages (FOAL'11), Pernambuco.

[43] Filho, F. C., Brito, P. H. S., Rubira, C. M. F.. (2005) “Modeling and Analysis of

Architectural Exceptions”, Proceedings of the Workshop on Rigorous Engineering




of Fault Tolerant Systems Event Information, in conjunction with Formal Methods

2005. University of Newcastle upon Tyne, UK, pags 112-121.

[44] Filho, F. C., Guerra, P. A.C., Rubira, C. M. F.. (2003) “An Architectural-Level

Exception-Handling System for Component-Based Applications”. Proceedings of

the Latin-American Symposium on Dependable Computing (LADC 2003).

[45] Filho, F. C., Brito, P. H. S., Rubira, C. M. F.. “A Framework for Analyzing

Exception Flow in Software Architectures”. Proceedings of the International

Conference on Software Engineering (ICSE 2005). Workshop on Architecting

Dependable Systems (WADS05).

[46] Filho, F. C., Romanovsky, A., Rubira, C. M. F.. (2006) "Verification of

coordinated exception handling". Proceedings of the ACM Symposium on Applied

Computing (SAC 2006), ACM Press, New York, NY, USA.

[47] Florio, V., Blondia, C.. (2008) “A Survey of Linguistic Structures for

Application-Level Fault Tolerance”, ACM Computing Surveys, Vol. 40, Nº2,

Article 6, Abril.

[48] Fu, C., Ryder, B. G.. (2007) "Exception-chain Analysis: REvealing Exception

Handling Architecture in Java Server Applications". Proceedings of The 29th

International Conference on Software Engineering (ICSE'07). IEEE Computer

Society.

[49] Garg, S., Puliafito, A., Telek, M., Trivedi, K.. (1998) "Analysis of Preventive

Maintenance in Transactions Based Software Systems". IEEE Transactions On

Computers, Vol 47, nº 1, Janeiro.

[50] Garcia, A. F., Beder, D. M., Rubira, C. M. F.. (2000) "An Exception Handling

Software Architecture for Developing Fault-Tolerant Software". 5th IEEE

International Symposium on High Assurance Systems Engineering (HASE). IEEE

Computer Society, pp311-320.

[51] Garcia, A. F., Rubira, C. M. F.. (2001) “An Architectural-based Reflective

Approach to Incorporating Exception Handling into Dependable Software”.

Advances in Exception Handling Techniques. Springer-Verlag, LNCS-2022, Abril,

pags. 189-206.

[52] Garcia, A., Romanovsky, A., Issamy, V.. (2010) “Introduction to the Special

Section on Exception Handling: From Requirements to Software Maintenance”.

IEEE Transactions on Software Engineering. IEEE Computer Society, Vol. 36, nº

2, March/April, pp. 147-149.

[53] Garlan, D.. (2003) “Formal Modeling and Analysis of Software Architecture:

Components, Connectors, and Events”, Formal Methods for Software Architectures,

Lecture Notes in Computer Science, 2804, Springer-Verlag, Berlin, pags.1-24.

[54] Gnesi, S., Lenzini, G., Martinelli, F.. (2005) "Logical Specification and Analysis

of Fault Tolerant Systems through Partial Model Checking". Electronic Notes in

Theorical Computer Science 118, Elsevier, pags 57-70.

[55] Gomes, J.S., Neto,P.A.M.S., Cruzes, D.S., Almeida, E.S.. (2011) "25 Years of

Software Engineering in Brazil: An Analysis of SBES History". 25th Brazilian

Symposium on Software Engineering (SBES 2011).

[56] Gokhale, S. S., Lyu, M. R., Trivedi, K. S.. (2006) "Incorporating Fault

Debugging Activities Into Software ReliabilityModels: A Simulation Approach".

IEEE Transactions on Reliability, Vol. 55, Nº. 2, Junho.

[57] Goodenough, J. B.. (1975) "Exception Handling: Issues and A Proposed

Notation". Communications of the ACM. Volume 18, Nº 12, December.

[58] Gobenko, A., Kharchenko, V.. (2008) "Experimenting with Exception

Propagation Mechanisms in Service-Oriented Architecture". Proceedings of the




Workshop on Exception-Handling (WEH’08).ACM 978-1-60558-229-0, november,

Atlanta, GA, USA.

[59] Gorbenko, A., Romanovsky, A., Kharchenko, V., Mikhaylichenko, A.. (2008)

"Experimenting with Exception Propagation Mechanisms in Service-Oriented

Architecture". Proceedings of Workshop on Exception-Handling (WEH), ACM

978-1-60558-229-0, Atlanta, November.

[60] Greenwood, P., Bartolomei, T., Figueiredo, E., Dosea, M., Garcia, A., Cacho,

N., Sant'Anna, C., Soares, S., Borba, P., Kulesza, Rashid, A.. (2007) "On the Impact

of Aspectual Decompositions on Design Stability: An empirical study". Proceedings

of the 21st European Conference on Object-Oriented Programming (ECOOP), pags.

176-200. Springer.

[61] Guelfi, N., Razavi, R., Romanovsky, A., Vandenbergh, S.. (2004) “DRIP

Catalyst: An MDE/MDA Method for Fault-tolerant Distributed Software Families

Development”. Proceedings of the OOPSLA and GPCE Workshop on Best

Practices for Model Driven Software Development.

[62] Guezzi, C..(2009) "Reflections on 40+ years of Software Engineering Research

and Beyond an Insider's View". International Conference on Software Engineering

(ICSE 2009).

[63] Harrison, N. B., Avgeriou, P.. (2008) "Incorporating Fault Tolerance Tactics in

Software Architecture Patterns". Proceedings of The International Workshop on

Software Engineering for Resilient Systems (SERENE). ACM 978-60558-275-

7/08/11, pp 9-18, Newcastle.

[64] Huang, C. Y., Lin, C. T.. (2006) "Software Reliability Analysis by Considering

Fault Dependency and Debugging Time Lag". IEEE Transactions on Reliability,

Vol. 55, Nº. 3, Setembro.

[65] Hoffman, K., Eugster, P.. (2008) "Towards Reusable Components Aspects: An

Empirical Study on Modularity and Obliviousness". Proceedings of the International

conference on Software Engineering (ICSE'08). ACM 978-1-60558-079-1/08/05,

Leipzig.

[66] Huang, G., Wu, Y.. (2011) "Towards Architecture-Level Middlware-Enabled

Exception Handling of Component-based Systems". Proceedings of the CBSE’11,

June 20–24, Boulder, Colorado, USA.

[67] Huth, M., Pradhan, S.. (2003) "Consistent Partial Model Checking". Electronic

Notes in Theorical Computer Science 73, Elsevier, pags 1-39.

[68] Issarny, V., Banatre, J.. (2001) “Architecture-based Exception Handling”.

Proceedings of the 34th Annual Hawaii International Conference on System

Sciences (HICSS-34), Vol. 9, IEEE Computer Society, Washington.

[69] Jacoby, K., Layton, H.. (1961) "Automation of Program Debugging".

Proceedings of the 16th ACM National Meeting, pags. 123.201-123.204.

[70] Jackson, D.. (2002) "Alloy: A Lightweight Object Modelling Notation". ACM

Transations on Software Engeneering and Methodology. Vol. 11, nº. 2, ACM Press,

New York, NY, USA.

[71] Jiang, S., Xu, B.. (2005) "An Efficient and Reliable Object-Oriented Exception

Handling Mechanism". ACM SIGPLAN Notices, Vol. 40, nº 2, February, ACM

Press.

[72] Jiang, S., Zhang, Y., Yan, D., Jian, Y..(2005)"An Approach to Automatic

Testing Exception Handling". ACM SIGPLAN Notices, Vol. 40, nº 8, pp 34-39.

[73] Jiang, S., Jiang, Y..(2007) "An Analysis Approach for Testing Exception

Handling Programs".ACM SIGPLAN Notices, Vol. 42, nº 4, pp 3-8.




[74] Johnson, R. E., Foote, B.. (1988), “Designing Reusable Classes”, Journal of

Object-Oriented Programming.

[75] Kalbarczyk, Z. T., Iyer, R. K., Bagchi, S.. (1999) "Chamaleon: A Software

Infrastructure for Adaptative Fault Tolerance". IEEE Transaction on Parallel and

Distributed systems, Vol 10, nº 6, junho.

[76] Kellens, A., Mens, K., Brichau, J., Gybels, K.. (2006) "Managing the evolution

of Aspect-Oriented Software with Model-based Pointcuts". Proceedings of the 20th

European Conference on Object-Oriented Programming (ECOOP), pags. 501-525.

Springer.

[77] Kiczales, G., Lamping, J., Mendhekar, A., Maeda,C., Lopes, C., Loingtier, J.-

M., Irwin, J.. (1997) “Aspect-Oriented Programming”. Proceedings of the 11th

European Conference on Object-Oriented Programming (ECOOP ’97), Finland,

Springer-Verlag, 1997, pp. 220-242.

[78] Kienzle, J.. (2008) “On Exception Handling in the Software Lifecycle”.

Proceedings of The Workshop on Exception Handling (WEH 2008).

[79] Kintala, C., Huang, Y., Koletis, N., Fulton, D..(1995) "Software Rejuvenation;

Analysis, Module and Applications".Proceedings of The Twenty-Fifth International

Symposium on Fault-Tolerant Computing (FTCS-25).

[80] Kljaich, J., Smith, B. S., Wojcik, A.S.. (1989) "Formal Verification of Fault

Tolerance Using Theorem-Proving Techniques". IEEE Transactions on Computers,

Vol. 38, nº 3, março.

[81] Koenig, A., Stroustrup, B.. (1993) "Exception Handling for C++. In The

Evolution of C++: Language Design in the Marketplace of Ideas". USENIX

Association book, MIT Press.

[82] Kumar, S., Cohen, P., Levesque, H.. (2000) "The Adaptive Agent Architecture:

Achieving Fault-Tolerance Using Persistent Broker Teams". Proceedings of The

Fourth International Conference on Multi-Agent Systems, IEEE Computer Society,

pags 159-166.

[83] Laprie, J.C.. (2001) “Dependability: Concepts, State-of-the-Art and Challenges”,

International Seminar, University of Newcastle Upon Tyne,

http://www.ncl.ac.uk/computing/research/seminars/pdfs/chapters/284.pdf. Acesso

em maio de 2012.

[84] Laprie,J.C.. (1985), “Dependable Computing and Fault Tolerance: Concepts and

Terminlogy”. IEEE Proceedings of FTCS-25, Volume III.

[85] Lemos, R., Guerra, P. A. C,. Rubira, F. M. C.. (2006) “A Fault-Tolerant

Architectural Approach for Dependable Systems”. IEEE Software, Special Issue on

Software Architectures Março/Abril.

[86] Lemos, R.. (2006) “Idealised Fault Tolerant Architectural Element”,

Proceedings of the Workshop on Architecting Dependable Systems (WADS06).

[87] Lerner, B. S., Christov, S., Osterweil, L. J., Bendraou, R., Kannengiesser, U.,

Wise, A.. (2010) "Exception Handling Pattern for Process Modeling". IEEE

Transactions On Software Engineering. IEEE Computer Society, Vol. 36, Nº 2,

MARCH/APRIL, pp 162-183.

[88] Lippert, M., Lopes, C. V.. (2000) "A Study on Exception Detection and

Handling Using Aspect-Oriented Programming". Proceedings of the 22th

International conference on Software Engineering (ICSE'00). ACM Press,

Limmerick.

[89] Loughran, N., Parlavantzas, N. Pinto, M., Fernàndez, L. F., Sànchez, P. Webster,

M., Colyer, A.. (2005) "Survey of Aspect-oriented Middleware". Acessado em 04

de Setembro de 2012, http://www.aosd-europe.net/deliverables/d8.pdf

http://www.ncl.ac.uk/computing/research/seminars/pdfs/chapters/284.pdf




[90] Lyu, M. R., Huang, Z., Sam K.S., Cai, S. X.. (2003) "An Empirical Study on

Testing and Fault Tolerance for Software Reliability Engineering".Proceedings of

the 14th International Symposium on Software Reliability Engineering (ISSRE’03).

[91] Maes, P.. (1987), “Concepts and Experiments in Computacional Reflection”,

ACM. SIGPLAN Notices, 22(12): 147-155.

[92] Majzik, I., Pataricza, A., Bondavalli, A.. (2003) “Stochastic Dependability

Analysis of System Architecture Based on UML Models, Architecting Dependable

Systems, LNCS 2677 , Lecture Notes in Computer Science, Springer-Verlag, Berlin,

Heidelberg, New York, pags.. 219–244.

[93] Marcadal, J., Enard, Q., Consel, C., Loriant, N..(2010) "A Domain-Specific

Approach to Architecturing Error Handling in Pervasive Computing".Proceedings of

the OOPSLA/SPLASH’10, October 17–21, 2010, Reno/Tahoe, Nevada, USA.

[94] McIlroy, D.. (1968), "Mass Produced Software Components", Software

Engineering: Report on a Conference Sponsored by the NATO Science Committee,

pp. 138 - 150.

[95] Medvidovic, N., Taylor, R. N.. (2000) “A Classification and Comparison

Framework for Software Architecture Description Languages”. IEEE Transactions

on Software Engineering vol. 26, nº 1, Janeiro.

[96] Medvidovic, N., Rosenblum, D. S., Redmiles, D. F., Robbins, J. E.. (2002)

“Modeling Software Architectures in the Unified Modeling Language”. ACM

Transactions on Software Engineering and Methodology (TOSEM). Vol. 11, nº 1,

Janeiro.

[97] Moorsel, A. V., Garg, S.,Vaidyanathan, K.,Trivedi, K..(1998) "A Methodology

for Detection and Estimation of Software Aging". Proceedings of The Ninth

International Symposium on Software Reliability Engineering.

[98] Mustafiz, S., Sun, X., Kienzle, J., Vangheluwe, H.. (2006) "Model-driven

assessment of use cases for dependable systems", in MoDELS 2006.

[99] Nehmer, N., Reuter, A.. (2008) "An Exception Handling Framework".

Proceedings of the 22th European Conference on Object-Oriented Programming

(ECOOP). Doctoral Symposium and PhD Student Workshop. Paphos, Cyprus.

[100] Nuseibeh, B., Easterbrook, S..(2000) "Requirements Engineering: A Roadmap",

in ACM ICSE 2000, The Future of Software Engineering, ed. A. Finkelstein.

[101] Ogasawara, T., Komatsu, H., Nakatani, T..(2006) "EDO: Exception-Directed

Optmization in Java".ACM Transactions on Programming Languages and Systems,

Vol. 28, No. 1, January, Pages 70–105.

[102] Owre, S., Rushby, J., Shankar, N., Henke, F.. (1995) "Formal Verification for

Fault-Tolerant Architectures: Prolegomena to the Design of PVS". IEEE

Transactions on Software Engineering, Vol. 21, nº 2, Fevereiro.

[103] Owre, S., Rajan, S., Rushby, J.M., Shankar, N., Srivas, M.. (1996) "PVS:

Combining Specification, Proof Checking, and Modl Checking". Lecture Notes in

Computer Science 1102, Computer-Aided Verification (CAV 96). Springer-Verlag,

pags 411--414.

[104] Pai, G. J., Dugan, J. B.. (2002) “Automatic Synthesis of Dynamic Fault Trees

from UML System Models”. Proceedings of the 13th International Symposium on

Software Reliability Engineering (ISSRE’02). IEEE Computer Society, Los

Alamitos, CA.

[105] Parnas, L. D.. (1972), "On the Criteria To Be Used in Decomposing Systems

into Modules," Communications ACM, vol. 15, pp. 1053-1058, 1972.

[106] Perry, D. E.. (1989). "The Inscape Environment". Proceedings of the 11th

International Conference on Software Engineering. pp 2–12.




[107] Perry, D. E., Wolf, A. L.. (1992) “Foundations for the Study of Software

Architecture”. SIGSOFT Software Engineering Notes, Vol. 17, nº 4, Oct 1992.

[108] Pfening, A., Garg, S., Puliafito, A., Telek, M., Trivedi, K..(1996) "Optimal

software Rejuvenation for Toleranting soft Failures". Performance Evaluation

Journal, Volume 27-28, outubro, Pags 491 - 506.

[109] Pham, H., Nordmann, L., Zhang, X.. (1999) "A General Imperfect-Software-

Debugging Model with S-Shaped Fault-Detection Rate". IEEE Transactions on

Reliability, Vol. 48, Nº. 2, Junho.

[110] Prins, J. F..(1982) "Automated Testing in APL An Application for Exception

Handling". Proceeding APL '82 Proceedings of the International Conference on

APL. ACM SIGAPL APL, volume 13, issue 1, pp 260-264.

[111] Qiu, X., Zhang, L., Lian, X.. (2010) "Static Analysis for Java Exception

Propagation Structure". Proceedings of the IEEE International Conference on

Progress in Informatics and Computing (PIC). IEEE Computer Society, vol. 2, pp

1040-1046.

[112] Weber, T. S.. (2002) “Um Roteiro para Exploração dos Conceitos Básicos de

Tolerância a Falhas”, www.inf.ufrgs.br/~taisy/disciplinas/textos/indiceroteiro.htm.

Acesso em maio de 2012.

[113] Weimer, W. R., Buse, R. P. L.. (2008) "Automatic Documentaion Inference for

Exceptions". Proceedings of the International Symposium on Software Testing and

Analysis (ISSTA’08), July 20–24, Seattle, Washington, USA. Copyright 2008

ACM978-1-60558-050-0/08/07.

[114] Wong, W. E., Wei, T., Qi, Y., Zhao, L.. (2008) "A Crosstab-based Statistical

Method for Effective Fault Localization". International Conference on Software

Testing, Verification, and Validation (ICST 2008), Lillehammer.

[115] Yurcik, W., Doss, D.. (2001) "Achieving Fault-Tolerant Software with

Rejuvenation and Reconfiguration". IEEE Software Julho/Agosto.

[116] Yu, Y., Jones, J. A., Harrold, M. J.. (2008) "An Empirical Study of The Effects

of Test-Suite Reduction on Fault Localization". Proceedings of The International

Conference on Software Engineering (ICSE 08), Leipzig.

[117] Randell, B.. (1975) "System Structure for Software Fault Tolerance". IEEE

Transactions on Software Engineering. IEEE Press SE-1, 1975.

[118] Rashid, A., Cottenier, T., Greewood, P., Chitchyan, R., Meunier R., Coelho R.,

Sudholt, M., Joosen, W.. (2012) "Aspect-Oriented Software Development in Pratice:

Tales from AOSD-Europe". Computer, IEEE Computer Society, february, Vol. 43,

nº2, pp-19-26.

[119] Rebêlo, H., Coelho, R., Lima, R., Leavens, G. T., Huisman, M., Mota, A.,

Castor, F.. (2011) "On the Interplay of Exception Handling and Design by Contract:

An Aspect-Oriented Recovery Approach".Proceeedings of the 13th Workshop on

Formal Techniques for Java-Like Programs(FTfJP’11). 25th European Conference

on Object-Oriented Programming (ECOOP) Lancaster, United Kingdom.

[120] Robillard, M. P., Murphy, G. C..(2003) "Static Analysis to Suppor the Evolution

of Exception Structure in Object-Oriented Systems". ACM Transactions on

Software Engineering and Methodology, Vol. 12, No. 2, April, Pages 191–221.

[121] Romanovsky, A., Xu, J., Randell, B..(1995) "Exception Handling and

Resolution in Distributed Object-Oriented Systems". IEEE Transactions on Parallel

and Distributed Systems, pp 545-552.

[122] Romanovsky, A., Dony, C., Knudsen, J. L., Tripathi, A.. (2001) "Advances in

Exception Handling Techniques". ISBN 3-540-41952-7, Springer-Verlag. Berlin,

Heidelberg, New York.

http://www.inf.ufrgs.br/~taisy/disciplinas/textos/indiceroteiro.htm




[123] Romanovsky, A., Guelfi, N., Muccini, H., Pelliccione, P.. (2010) “An

Introduction to Software Engineering and Fault Tolerance”.

http://arxiv.org/abs/1011.1551v1, acessado em maio de 2012.

[124] Rubira, C. M. F., Lemos, R., Ferreira, G. R. M., Filho, F. C.. (2004) “Exception

Handling in the Development of Dependable Component-based Systems”.

Software-Practice and Experience, Wiley InterScience, Dezembro, pags. 195-236.

[125] Ryder, B. G., Soffa, M. L., Burnett, M.. (2005)"The Impact of Software

Engineering Research on Modern Programming Languages". ACM Transactions on

Software Engineering and Methodology. Vol. 14, Nº. 4, october, pp 431–477.

[126] Schlichting, R. D., Schneider, F. B.. (1983) "Fail-stop processors: an approach to

designing fault-tolerant computing systems". ACM Transactions on Computer

Systems (TOCS), Volume 1, Issue 3, pags 222 - 238.

[127] Shah, H., Gorg, C., Harrold, M. J.. (2008) "Visualization of Exception Handlinh

Constructs to Support Program Understanding". Proceedings of ACM Symposium

on Software Visualization (SOFTVIS). ACM 978-1-60558-112-5/08/0009,

Herrsching am Ammersee.

[128] Shaw, M., Clements, P.. (1997) “A Field Guide to Boxology: Preliminary

Classification of Architectural Styles for Software Systems”, Proceedings of the

21st International Computer Software and Applications Conference

(COMPSAC97).

[129] Shui, A., Mustafiz, S., Kienzle, J., Dony, C.. (2005) "Exceptional Use Cases",

Proceedings of the MoDELS 2005.

[130] Shui, A., Mustafiz, S., Kienzle, J.. (2006) "Exception-aware requirements

elicitation with use cases". Advanced Topics in Exception Handling Techniques,

Springer, Berlin.

[131] Silva, J.B., Barreto, L.P.. (2008) “Separação e Validação de Regras de Negócios

MDA usando Programação Orientada a Aspectos”. II Simpósio Brasileiro de

Componentes e Arquiteturas de Software, Porto Alegre.

[132] Silva, J. B.. (2011) "Proposta de uma Arquitetura para o Gerenciamento de

Regras de Negócio em LPS com Base na MDA". Proceedings of The International

Workshop on Metamodels Ontologies and Web Semantic Technologies, Vol. 776,

pags 99-104.

[133] Sinha, S., Harrold, M. J.. (1998) "Analysis of Prograns with Exception-Handling

Constructs". Proceedings of Internacional Conference on Software Maintenance

(ICSM). IEEE computer Society, Washington, pag 348.

[134] Sinha S., Harrold, M. J..(1999) "Criteria for Testing Exception-Handling

Construts in Java Programs".Proceedings of the IEEE International Conference on

Software Maintenance (ICSM).IEEE Computer Society, ISBN:0-7695-0016-1,pp

265.

[135] Sinha, S., Harrold, M. J..(2000) "Analysis and Testing of Programs with

Exception Handling Constructs". IEEE Transactions on Software Engineering,

vol.26, Nº.9, September.

[136] Sommerville, I.. (2007) “Software Engineering”. Pearson Education Limited, 8th

edition, Edinburg Gate.

[137] Sozer, H.. (2009) “Architecting Fault Tolerant Systems”, CTIT Ph.D. Thesis

series no. 09-135. ISBN 978-90-365-2788-0. Centre for Telematics and Information

Technology (CTIT), AE Enschede, Holanda.

[138] Taveira, J. C., Queiroz, C., Lima, R., Saraiva, J., Soares, S., Oliveira, H.,

Temudo, N., Araújo, A., Amorim, J., Castor, F., Barreiros, E.. (2009) "Assesssing

http://arxiv.org/abs/1011.1551v1




Intra-Application Exception Handling Reuse with Aspects". Proceedings of the

XXVIII Brazilian Symposium on Software Engineering (SBES).

[139] Taveira, J., Oliveira, H., Castor, F., Soares, S.. (2010) "On Inter-Application

Reuse of Exception Handling Aspects". Proceedings of the AOSD'2010 Workshop

on Empirical Evaluation of Software Composition Techniques (ESCOT'2010).

Rennes, France.

[140] Tizzei, L. P., Dias, M., Rubira, C. M. F., Garcia, A., Lee, J.. (2011)

"Components Meet Aspects: Assessing Design Stabbility of Software Product

Line". Information and software Technology, Vol. 53. Elsevier, pp 121-136.

[141] Tracey, N., Clark, J., Mander, K., McDermin, J..(2000) "Automated Test-data

Generation for Exception Conditions". Software-Pratice And Experience. volume 30

pp 61-79.

[142] Trivedi, K. S., Vaidyanathan, K., Goseva-Popstojanova, K.. (2000) "Modeling

and Analysis of Software Aging and Rejuvenation". Proceedings of the 33rd Annual

Simulation Symposium (SS 2000).

[143] Vergilio, S. R., Colanzi, T. E., Pozo, A. T. R. , Assunção, W. K. G..(2011)

"Search Based Software Engineering: A Review from the Brazilian Symposium on

Software Engineering". 25th Brazilian Symposium on Software Engineering (SBES

2011).

[144] Yokogawa, T., Tsuchiya, T., Kikuno, T.. (2001) "Automatic Verification of

Fault Tolerance using Model Checking". Proceeding of The Pacific Rim

International Symposium on Dependable Computing, IEEE Computer Society, Los

Alamitos, CA.

[145] Xu, J., Randell, B., Romanovsky, A., Rubira, C. M. F., Stroud,R. J., Wu, Z..

(1995) "Fault Tolerance In Concurrent Object-oriented Software Through

Coordinated Error Recovery". Proceedings of the Twenty-Fifth International

Symposium on Fault-Tolerant Computing, IEEE Computer Society,

Washington,DC, USA.

[146] Zhang, Y., Jiang, S., Li, W., Yuan, G.. (2009) "An Approach to Analyzing Inter-

Class Control Dependence of Programs with Exception-Handling". Proceegins of

the International Conference on Computational Intelligence and Software

Engineering (CiSE). IEEE Computer Society. pp1-4.

Documents

Tratamento de Falhas Residuais Durante o Design de Sistemas de Software – O Estado da Arte