Tratamento de Falhas Residuais Durante o Design de Sistemas de Software - O Estado Da Arte

Tratamento de Falhas Residuais Durante o Design de Sistemas de Software O Estado da Arte
Jaguaraci Batista Silva Instituto de Cincia e Tecnologia, Universidade Federal de So Paulo Campus So Jos dos Campos, So Paulo-SP jaguaraci.silva@unifesp.br
Resumo: Para garantir a confiabilidade dos sistemas de software, vrias tcnicas

podem ser empregadas, cuja forma mais comum a utilizao de mecanismos de tolerncia a falhas. Eles permitem que o sistema possa evitar falhas residuais graves que no podem ser toleradas durante a sua execuo. Entretanto, essas tcnicas geralmente so empregadas tardiamente durante a construo dos softwares e a necessidade de incluir tais mecanismos (e.g. tratamento de exceo) nas fases iniciais, tem sido defendida por muitos pesquisadores como uma das principais abordagens para se alcanar a confiabilidade. Neste estudo, so apresentadas diversas abordagens, que relacionadas com as prticas de Engenharia de Software, representam o atual estado da arte no tratamento de falhas residuais. Promovendo uma viso abrangente e aprofundada nesse mbito, o trabalho visa: (i) a conhecer a direo e evoluo das pesquisas, (ii) como esto sendo aplicadas e (iii) quais as suas limitaes.
I. INTRODUO
A origem do termo confiabilidade apareceu em 1830, quando Babbage projetou um dos primeiros mecanismos de clculo e, aps a primeira gerao de computadores, nas duas dcadas seguintes (Avizienis et al, 2004). Sistemas de software esto presentes em toda parte controlando muitos dispositivos utilizados todos os dias (e.g. computador pessoal, celulares, caixas bancrios, fornos industriais, avies, foguetes), incluindo os sistemas crticos, cujo tipo de aplicao no pode tolerar um mau funcionamento, pois aumentado drasticamente o risco s pessoas ou ainda causar grandes perdas econmicas s empresas. Muitos sistemas falham diariamente e algumas falhas mudaram a direo das pesquisas na rea de tolerncia a falhas (Avizienis, 2001). Assim, a preveno de falhas passou a ser utilizada para incluir um controle mais rigoroso durante a fase de anlise e projeto de software, estabelecendo um processo de construo de software com atividades que buscam a identificao de falhas antes da sua implementao (Avizienis et al, 2004). A necessidade de melhoria na qualidade software, empregando os mecanismos de tolerncia 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 viso anterior, pois as falhas em hardware foram diminuindo atravs dos anos como consequncia do aumento da qualidade dos seus componentes. Em 1993, um relatrio da NRC (National Research Council) apontou que 81% do total das interrupes nos sistemas foram causadas por falhas em software (Florio, 2008). A nica alternativa eficiente seria alcanar a confiabilidade incorporando mecanismos de tolerncia a falhas na camada de software (Randell, 1975). Assim essas tcnicas, especialmente o tratamento de exceo, foram incorporadas s necessidades de confiabilidade e deteco de falhas na Engenharia de Software.
Relatrio Tcnico de Pesquisa - Mestrado em Cincia da Computao - 25/06/2012 Instituto de Cincia e Tecnologia (ICT) - UNIFESP - So Jos dos Campos. Autor: Jaguaraci Batista Silva
O tratamento de excees foi um grande tema de debate na dcada de 90 na conferncia USENIX C++, onde Koenig e Stroustrup (Koenig e Stroustrup, 1993) apresentaram um modelo para tratamento de excees Orientado a Objetos. Recentemente, a tecnologia ou paradigma de Programao Orientada a Aspectos (POA) descreve o tratamento de excees como uma das preocupaes transversais em um programa OO e muitas pesquisas destacaram avanos utilizando linguagens de programao orientadas a aspectos, onde a linguagem AspectJ, uma extenso da linguagem de programao Java, aparece frequentemente nesses estudos. A integrao dos mecanismos de tratamento de exceo, combinados com a tecnologia de POA levantaram diversas questes. Embora a tecnologia possa ser utilizada para promover a modularidade e reutilizao de cdigo no tratamento de exceo (Lippert e Lopes, 2000), possvel observar em outros estudos que tambm pode aumentar a propenso a defeitos nos sistemas, ocasionando uma maior evidncia de excees no capturadas. Alm disso, o seu tratamento pode ser feito de forma no intencional, quando as excees so lanadas e capturadas de forma inesperada por existir algum tratamento no cdigo de um aspecto (Figueroa e Tanter, 2011). Outro problema grave a transparncia, que tem sido uma propriedade controversa desde as primeiras pesquisas envolvendo POA. A falta de consistncia entre os componentes e os aspectos tende a ocasionar implementaes 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 cdigo de tratamento de excees sob diversas perspectivas, envolvendo as prticas de engenharia de software e outras tcnicas conhecidas, a exemplo do Design por Contrato (DbC). Muitos autores acreditam que esses problemas poderiam ser contornados, com a insero das tcnicas de tolerncia a falhas nas fases iniciais do desenvolvimento de softwares, pois geralmente, so 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). Porm, 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. persistncia, log, trace) e de domnio de aplicao (e.g. regras de negcio) dificultando a utilizao das tcnicas desde o incio do desenvolvimento (Taveira et al, 2010). Assim, um grande nmero de estudos foi conduzido tentando compreender onde e como a tolerncia a falhas pode ser integrada no ciclo de vida do software. Desta forma, este estudo tem como objetivo: (i) conhecer a direo das pesquisas que visam o tratamento de falhas residuais relacionadas com as prticas de engenharia de software, (ii) como esto sendo aplicadas e (iii) quais as limitaes das abordagens mais recentes. Espera-se investigar a evoluo dessas pesquisas, principalmente, as que utilizam os mecanismos de recuperao dos estados anterior e seguinte ao erro e atravs de uma perspectiva histrica da relao entre as reas. Tambm, apresentar panorama sobre como essas tcnicas esto sendo empregadas no ciclo de vida do software.
A seo II apresenta os conceitos bsicos sobre confiabilidade de forma breve e justifica porque perseguir a confiana nos sistemas de software. A seo III descreve como os sistemas podem alcanar dependabilidade tolerando suas falhas e apresenta as suas principais tcnicas. Na seo IV o estudo cria uma relao entre as reas de tolerncia a falhas e engenharia de software, propondo uma viso particular de como os temas relacionados confiabilidade esto sendo tratados no ciclo de vida do software. Atravs de uma anlise das reas de pesquisa da engenharia de software, o estudo tambm evidencia nas suas prticas como as tcnicas de tolerncia a falhas esto sendo empregadas na seo V. A direo das pesquisas que abordam o tratamento das falhas residuais, que envolve o tratamento do estado anterior e seguinte ao erro na seo VI e as situaes excepcionais atravs das linguagens de programao na seo VII. Na seo VIII apresentado um senso comum sobre os estudos recentes que utilizam a tecnologia de programao orientada a aspectos em linguagens de programao modernas. Por fim, a concluso e referncias utilizadas esto descritas na parte final deste estudo.
II. CONCEITOS BSICOS SOBRE CONFIABILIDADE

A palavra confiabilidade pode ser definida pela capacidade de um sistema fornecer um servio considerado confivel. Esta definio refora a necessidade de confiana, onde o critrio para decidir se o servio confivel dada pela capacidade que um sistema possui em evitar falhas graves que no podem ser toleradas durante a sua utilizao (Laprie, 1985). A origem do termo confiabilidade apareceu em 1830, quando Babbage projetou um dos primeiros mecanismos de clculo, e aps a primeira gerao de computadores, nas duas dcadas seguintes (Avizienis et al, 2004). Tambm, segundo (Avizienis et al, 2000) e (Avizienis, 1967) os primeiros computadores j mostravam uma preocupao com dependabilidade, empregando tcnicas de redundncia para mascarar falhas de componentes menos confiveis, controle de erros e diagnstico de componentes com falhas atravs das atividades de verificao e validao. As tcnicas para alcanar confiabilidade comearam a ganhar importncia na comunidade cientfica em 1967, quando pesquisadores propuseram uma integrao das prticas de deteco, diagnstico e recuperao de falhas. Especialmente, com a formao de comits de pesquisa na rea de Computao Tolervel a Falhas em 1970 (IEEE-CS TC) e posteriormente de Computao Confivel e Tolervel 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 ento definidas em duas categorias principais: intencionais e acidentais, onde as intencionais eram causadas por cdigo malicioso e intruses e as acidentais por enganos durante as fases de concepo e uso dos sistemas. Uma pesquisa exploratria sobre a integrao das reas de tolerncia a falhas e segurana de sistemas contra as falhas intencionais foi iniciada nas universidades de Newcastle Upon Tyne, Toulouse e Los Angeles California, em meados da dcada de 80. Logo depois, aconteceu a 1 Conferncia sobre Computao Confivel (IFIP) em 1989 e as seguintes seis edies ajudaram a promover uma maior sinergia entre as comunidades de confiabilidade e segurana apresentando um avano significativo das estratgias 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 trs partes (Laprie, 1985) (Avizienis et al, 2004): tratamento das ameaas, dos atributos, e os meios pelos quais a confiabilidade poderia ser alcanada (Figura 1). Os atributos de: confiabilidade, segurana, integridade e manuteno indicam grupos de mtricas 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 mximo de sua indisponibilidade e indica formas alternativas de tolerar ou no a sua interrupo. A confiabilidade define as caractersticas de correo para continuidade a partir do ponto em que foi encontrada uma falha. A segurana preocupa-se com as consequncias desastrosas de um mau comportamento do sistema e a integridade com a ausncia de alteraes imprprias e a manuteno com a capacidade do sistema sofrer modificaes e reparos para a sua correo.
Figura1- rvore de Confiabilidade (Avizienis, 2001).
Alm dos principais conceitos de confiabilidade, em (Weber, 2002) tambm possvel encontrar uma terminologia semelhante sobre os tipos de ameaas existentes (threats) que impendem os sistemas alcanarem a confiana desejada (Figura1): o defeito, o erro e a falha. Um defeito (failure) definido como um desvio da especificao, que no pode ser tolerado, mas deve ser evitado. Define-se que um sistema est em estado errneo, ou em erro, se o processamento posterior a partir desse estado pode levar a um defeito. Um defeito tambm pode ser definido pela frustrao 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 fsica ou algortmica do erro. Em (Avizienis et al, 2004), conforme a Figura 1, so apresentadas tcnicas de preveno, remoo, tolerncia e previso de falhas, meios os quais possvel implementar confiabilidade nos sistemas. A preveno de falhas pode ser utilizada para incluir um controle mais rigoroso durante a fase de anlise e projeto de software, estabelecendo um processo de construo de software com atividades que visam a identificao de falhas antes da sua implementao. A tcnica de remoo utiliza ferramentas de verificao, validao e diagnstico para reduzir o nmero de falhas durante a fase de implementao do software. Embora sejam utilizadas nas etapas iniciais e durante a implementao do software, essas tcnicas no oferecem garantia
para um tratamento adequado as diversas falhas que podem acontecer, pois todos os componentes envolvidos durante a execuo do software tambm so passveis de erros (e.g. sistema operacional, banco de dados, middlewares, protocolos de transporte de mensagens). A tcnica de tolerncia a falhas visa a garantia da correo durante a execuo do software mesmo quando h falhas. Desse modo, assegurado a continuidade do sistema atendendo aos requisitos exigidos. Por fim, a preveno de falhas objetiva a previso dos estados em que podem ocorrer as falhas e suas provveis consequncias. De forma pragmtica possvel notar que se faz necessria uma combinao de todos esses meios para assegurar a confiana em um sistema, sendo fcil compreender que as tcnicas oscilam em torno das falhas, tornando-se possvel impedi-las ou elimin-las aplicando uma tcnica adequada. Porm, as falhas remanescentes ou residuais, tambm devem ser toleradas em tempo de execuo (Romanovsky et al, 2010).
III.
TOLERNCIA A FALHAS
Durante muitos anos as pesquisas na rea de tolerncia 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 necessria para atingir os atributos de disponibilidade e integridade dos dados, at Randell (Florio, 2008 (Randell, 1975)) perceber em seus estudos, que tal afirmao estava longe de ser verdade. Segundo ele, as falhas dos componentes de hardware so apenas uma fonte de insegurana nos sistemas de computao, o que diminui a sua importncia 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 Histria da Computao (Avizienis, 2001).
Os sistemas de software esto presentes em toda parte, controlando muitos dispositivos todos os dias (e.g. computador pessoal, celulares, caixas bancrios, fornos industriais, avies, foguetes), incluindo os sistemas crticos, cujo tipo de aplicao no pode tolerar um mau funcionamento, pois aumentado drasticamente o risco s pessoas ou ainda causar grandes perdas econmicas as empresas. Na verdade, muitos sistemas falham diariamente e algumas falhas mudaram a direo das pesquisas na rea de tolerncia a falhas. Em setembro de 2001, diversos pesquisadores se reuniram em um simpsio 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 tambm as principais falhas em sistemas crticos na histria, atravs de diversas perspectivas (Figura 2). Com base neste estudo, as principais falhas e defeitos da histrica puderam ser analisados sob as ticas de falhas fsicas dos componentes de hardware, falhas em tempo de design dos sistemas e aps a sua implantao, quando sofrem a interao das pessoas ou outros sistemas ou dispositivos. Tambm, o simpsio inclui os defeitos encontrados de forma localizada em um dado ponto do sistema ou de forma distribuda, no s no mesmo sistema, mas em todos os outros pontos relacionados com a execuo de uma determinada funcionalidade. Alm das consequncias quando alguns atributos de dependabilidade no so assegurados nos sistemas: disponibilidade e confiabilidade, segurana no acesso e confidencialidade dos seus dados. Entretanto, apenas classificar as falhas e defeitos no asseguraria os atributos de confiabilidade. Era preciso investigar novas tcnicas para preveno de defeitos, fazendo-se necessrio observar diversos pontos de vistas e classific-los quando da sua ocorrncia 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: fenomenolgica (e.g. ausncia de energia eltrica, raios, tornados), de natureza acidental ou intencional seja maliciosa ou no, quando encontradas na fase de design ou uso dos sistemas, no contexto do domnio ao qual o sistema utilizado, podendo ser interno ou externo aos limites do sistema e quanto a sua persistncia, pois as falhas podem ser temporrias ou permanentes.
Figura 3 Pontos de Vista e Categoria de Falhas (Florio, 2008). Relatrio Tcnico de Pesquisa - Mestrado em Cincia da Computao - 25/06/2012 Instituto de Cincia e Tecnologia (ICT) - UNIFESP - So Jos dos Campos. Autor: Jaguaraci Batista Silva
A necessidade de melhoria na qualidade software, empregando mecanismos de tolerncia 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 relatrio da NRC (National Research Council) apontou que 81% do total de interrupes nos sistemas foram causadas por falhas em software (Florio, 2008). Alm disso, os sistemas cresciam em acessos, como hoje em dia, cada vez mais em ambientes abertos e distribudos, atravs das redes de computadores, onde muitas vezes so construdos com alto acoplamento e baixa coeso, resultando em uma estrutura mais propensa a defeitos (Silva e Barreto, 2008). Devido sua prpria natureza complexa e temporal, via trocas de mensagens e clculos nesses ambientes, nenhuma quantidade de verificao, validao e testes pode eliminar totalmente as falhas futuras e promover a confiana na sua consistncia e disponibilidade dos seus dados (Florio, 2008). A nica alternativa eficiente, segundo (Florino, 2008, (Randell, 1975)), seria alcanar a confiabilidade incorporando mecanismos de tolerncia a falhas na camada de software e adotar prticas de reuso como: separao de interesses (Parnas, 1972), padres de projeto (Alexander, 1977), reflexo computacional (Maes, 1987), desenvolvimento baseado em componentes (MCllroy, 1968), frameworks (Johnson e Foote, 1988), composio adaptativa (Weiser, 1993), programao orientada aspectos (Kiczales, 1997) e utilizao de middlewares (Loughran et al, 2005). Se por um lado a utilizao dessas abordagens trouxe melhoria na qualidade dos softwares, por outro aumentou a complexidade na sua construo, e por consequncia, aumentaram tambm os defeitos durante o design e uso dos sistemas de software (Silva e Barreto, 2008). Dessa forma, para no excluir a camada de software de uma estratgia de tolerncia a falhas preciso aplicar tambm o princpio de comunicao 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 no seja possvel garantir a confiana no canal de comunicao durante todo o percurso dos dados, a confiabilidade pode ser alcanada nos extremos dessa comunicao. Empregando adequadamente as tcnicas para tolerar falhas nas extremidades, mantendo os sistemas de software funcionando corretamente, de acordo com as suas especificaes. A definio de tolerncia a falhas pode ser dada por: ...um sistema tolerante a falhas se os seus programas podem ser executados corretamente, apesar da ocorrncia de falhas..." (Avizienis, 1967). "A tolerncia a falhas visa a preservar a entrega correta de um servio mesmo na presena de falhas, geralmente implementado por deteco de erros e subsequente recuperao do sistema." (Avizienis, Randell e Laprie, 2000). A tolerncia a falhas que visa a evitar o defeito, realizada atravs da deteco de erros e recuperao do sistema. (Avizienis, Randell e Laprie, 2004).
Conforme as definies, a sua essncia a deteco de erros e o seu tratamento para recuperao do sistema. Segundo (Anderson e Lee, 1981), tolerar falhas exige-se tambm empregar tcnicas de confinamento e avaliao do erro. De um modo geral, a tolerncia alcanada utilizando as tcnicas de deteco e recuperao de erros e tratamento da falha (Romanovsky et al, 2010). As tcnicas utilizadas na fase de
deteco podem envolver prticas de replicao, detectores de defeitos e testes estruturais. A recuperao de erros ocorre aps a deteco e envolve a troca do estado atual incorreto para um estado livre de falhas, podendo ser feito de duas formas: recuperao por retorno (estado anterior ao erro) e por avano (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. TOLERNCIA A FALHAS E A ENGENHARIA DE SOFTWARE

Apesar de serem investigadas h bastante tempo, a utilizao de tcnicas de tolerncia a falhas em software, especialmente os Tratadores de Exceo (TE) (Cristian, 1982), normalmente so 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. persistncia, log, trace) e de domnio de aplicao (e.g. regras de negcio) dificultando a padronizao de tcnicas para facilitar o uso de TE desde o incio do desenvolvimento de software (Taveira et al, 2010). Assim, um grande nmero de estudos foi conduzido at agora tentando compreender onde e como a tolerncia a falhas pode ser integrada no de ciclo de vida do software.
Figura 4 Pesquisas na rea de Engenharia de Software Relacionadas com Tolerncia a Falhas.
A engenharia de software (ES) um campo relativamente novo e emergente da cincia da computao. Foi reconhecida na conferncia da OTAN em 1968 em Garmisch, Alemanha (Romanovsky et al, 2010). O ICSE (International Conference on Software Enginneering) (Guezzi, 2009) e o SBES (Simpsio 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 relao entre os conceitos de tolerncias a falhas com os tpicos de pesquisa do SBES. Aps, foram identificados os tpicos do ICSE para estabelecer uma relao das pesquisas nacionais e internacionais. De acordo com a Figura 4, as pesquisas relacionadas com engenharia de software e o emprego de tcnicas de tolerncia a falhas tm sua principal concentrao em testes de software, alm da anlise e especificao de requisitos. Isso significa que, embora a associao semntica entre os tpicos de pesquisa e tcnicas de tolerncia a falhas baseadas em uma taxonomia (Avisenis, 2004) possa haver algum erro de interpretao, pois no houve um estudo aprofundado desta relao, esse resultado est em conformidade com pesquisas realizadas anteriormente (Verglio et al, 2011) (Guezzi, 2009) (Lyu et al, 2003).
Figura 5 Tpicos de Pesquisas do SBES e ICSE Relacionados com Tolerncia a Falhas.
J a Figura 5, com base nos dados analisados em (Gomes et al, 2011) e (Guezzi, 2009), exibe uma sincronia dos tpicos tratados no Brasil e no exterior. O que demonstra mais uma vez, que as prticas de teste de software e anlise e especificao de requisitos tambm esto entre as principais linhas de pesquisa na principal e mais importante conferncia da rea no mundo (ICSE). Com base na anlise semntica feita anteriormente, relacionado tcnicas e prticas de cada rea, possvel afirmar que as tcnicas esto inseridas no ciclo de desenvolvimento desde a fase de anlise at a manuteno dos sistemas, porm seria necessrio explorar outros estudos para comprovar a sua aplicao de fato. Vale ressaltar ainda, que no h dados que possa relacionar o aumento ou diminuio nas linhas de pesquisa apresentadas pelo SBES. Tambm, as prticas de MDD (Model-driven Development) e MDA (Model-driven Architecture), que empregam tcnicas de confiabilidade (Silva e Barreto, 2008), no apareceram nas pesquisas. Foi possvel concluir nas anlises, que os tpicos relacionados com as tcnicas de confiabilidade tm despertado maior interesse dos pesquisadores na rea de engenharia de software (Guezzi, 2009) e tolerncia a falhas (Romanovsky et al, 2010). Desta forma, como base nos objetivos descritos nesta seo, foi possvel conhecer onde as tcnicas esto sendo empregadas, porm, ainda se faz necessrio investigar como esto sendo aplicadas em conjunto com as prticas de engenharia de software.
V. COMO AS TCNICAS PARA TOLERAR FALHAS RESIDUAIS DE SOFTWARE ESTO SENDO APLICADAS?
Atravs de uma breve anlise da relao entre pesquisas em engenharia de software envolvendo as tcnicas de tolerncia a falhas (Seo IV), foi possvel identificar as
seguintes reas de pesquisa: requisitos, manuteno e reengenharia de software, verificao e validao e design de software. Segundo (Sommerville, 2007), para alcanar os atributos de confiabilidade usando as prticas de engenharia de software, necessrio existir um processo de software com as atividades de inspeo e gerenciamento de requisitos, verificao de modelos, design e inspeo de cdigo, anlise esttica, planejamento e gerenciamento testes e de configurao de verses, onde: Inspeo de requisitos possui a inteno de descobrir problemas com as especificaes de sistemas, porque uma alta proporo de falhas durante a entrega de softwares causada pelos erros de especificao. Se esses erros puderem ser descobertos e eliminados na fase de especificao esta classe de falha ir ser minimizada. Gerenciamento de requisitos preocupa-se em manter o controle de mudanas e rastreabilide de requisitos durante a concepo e construo do sistema. Muitos erros nas entregas dos sistemas so resultados da ausncia de uma gerncia efetiva das mudana de requisitos na fase de design e implementao do sistema. Verificao de modelos envolve anlise automtica com uso de ferramentas CASE para garantir a consistncia interna e externa dos modelos que representam as especificaes dos sistemas. A consistncia interna significa que um nico modelo consistente, enquanto a externa que verifica a assertividade dos diferentes modelos de acordo com a sua especificao (e.g. modelo de estados e de objetos). Design e inspeo de cdigo so atividades baseadas em uma lista de verificao de falhas comuns e possui a inteno de revelar e corrigir defeitos antes dos testes dos sistemas. Anlise esttica uma tcnica automatizada de anlise de cdigo, onde o programa analisado em detalhes para procurar as condies de erros em potencial, porm sem verificar o sistema em tempo de execuo. Planejamento e gerenciamento de testes exigem um conjunto de testes para verificao e validao do sistema, os testes podem utilizar anlise dinmica para assegurar, em sua cobertura, a assertividade dos requisitos em relao ao cdigo-fonte do sistema usando uma linguagem de programao. Gerenciamento da configurao previne erros em sistemas pela incluso de um componente incorreto ou a sua verso atravs do gerenciamento de suas verses consonante com as mudanas de requisitos e dependncias internas e externas. Com base nesta anlise inicial, sero apresentados os principais estudos de cada campo da engenharia de software, procurando demonstrar como as tcnicas de tolerncia a falhas esto sendo investigadas em conjunto com as prticas de engenharia de software.
De acordo a viso de Sommerville (Sommerville, 2007), este estudo procurou relacionar as pesquisas encontradas por reas temtica, por j serem bastante conhecidas pelas principais conferncias 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 so 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 tm 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, situaes excepcionais no requisitos e fornecem uma extenso 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 nvel de requisitos e como esses requisitos conduzem a especificao e design desses componentes de acordo com um processo de software especfico para este fim. Em (Mustafiz et al, 2006) uma abordagem foi criada para analisar a segurana e confiabilidade dos requisitos com base nos casos de uso, onde os casos de uso normais so estendidos para tratar as situaes excepcionais. De acordo com (Shui et al, 2005), os casos de uso so anotados com sua probabilidade de sucesso e depois seus dados so traduzidos e analisados em grficos exibindo o grau de confiabilidade da especificao.
V.II - Manuteno e Reengenharia

Os defeitos so uma das principais causas de falhas em software e cada vez mais so exploradas em ataques maliciosos. A tolerncia a falhas bizantinas permite que os sistemas sejam replicados para mascarar erros do software, porm a sua implantao custosa (Rodrigues, 2001) e as tcnicas de rejuvenescimento so alvo de muitas pesquisas. Diversos estudos investigaram o fenmeno do envelhecimento de software, que enfatiza a sua degradao no atendimento s suas funcionalidades ao longo do tempo. O rejuvenescimento tambm uma tcnica de tolerncia a falhas que combate o envelhecimento atravs das prticas de reeengenharia e manuteno 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 prticas tambm so realizadas durante as atividades de manuteno (e.g. teste, debugging), porm, sero abordadas mais adiante nesta seo. Vrias pesquisas envolvendo rejuvenencimento de software foram apresentadas ao longo do tempo e algumas se destacam por apresentar modelos de previso, deciso e custos. Em (Pfening et al, 1996) foi criado um modelo para previso de envelhecimento. Outro modelo foi apresentado em (Kintala et al, 1995) para analisar o rejuvenescimento de forma constante em um ambiente de execuo contnua, onde o tempo de inatividade do software expresso em custos. Em (Garg et al, 1998) foi criado um outro modelo para tratamento de transaes onde foram includas polticas de manuteno preventiva e formas para alcanar 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 avaliao da eficcia do gerenciamento de falhas do software e como determinar o tempo ideal para realizar as atividades de manuteno atravs de modelos estocsticos. Outras tcnicas de redundncia tambm foram investigadas para dar uma sobrevida aos sistemas de software. Em (Chandra e Chen, 2000) foram pesquisadas tcnicas genricas de recuperao com a implementao de pares de processos e em (Chen e Avizienis, 1996) replicaes de n verses 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 permanea operacional em (Yourcik e Boss, 2001).
A reduo de custo envolvendo a manuteno de software motivaram outras pesquisas para aumentar o potencial de reutilizao das suas implementaes, alm do aumento do tempo da disponibilidade do software. Em (Castro et al, 2003) foram criadas rplicas de servios que podem ser reparadas periodicamente usando o estado armazenado por rplicas corretas, e por consequncia, cada rplica pode executar implementaes de servios distintos, o que reduz a probabilidade de falhas. Outros estudos proposeram abordagens adaptativas e reconfigurveis para diminuir os impactos do envelhecimento, como em (Kalbarczyk et al, 1999) e aproximaes emergentes como o GRID computacional (Bolsica et al, 2002) e computao em nuvem (Birman et al, 2009).
V.III - Verificao e Validao

Tcnicas de tolerncia a falhas no so suficientes para alcanar dependabilidade, uma vez que as falhas inesperadas no podem ser evitadas. Alm disso, importante notar que at os sistemas tolerantes a falhas, inevitavelmente, contm falhas residuais. Tcnicas de verificao e validao (V & V) so meios eficazes para garantir que as propriedades esperadas e as exigncias das especificaes sejam satisfeitas em diversos modelos e suas respectivas implementaes, ajudando na remoo de falhas dos sistemas. Tcnicas de V & V visam garantia da correo de um sistema de software ou pelo menos reduzir o nmero ou a gravidade das falhas tanto durante o desenvolvimento quanto aps a sua implantao. Existem dois tipos de mtodos de verificao: os mtodos exaustivos que conduzem uma explorao exaustiva de todos os comportamentos possveis e no exaustivo, que explora apenas alguns dos comportamentos possveis. A classe no exaustiva possui tcnicas de verificao de modelos, provadores de teoremas e solucionadores de restries. Na classe no exaustiva existem os testes e simulaes, tcnicas que so amplamente utilizadas, mas que podem facilmente deixar passar erros significativos quando verificam a complexidade de grandes sistemas (Romanovsky et al, 2010). Na literatura vrias abordagens tm sido propostas nos ltimos anos tentando aplicar tcnicas de V & V em sistemas tolerantes a falhas e este estudo apresenta como as tcnicas de verificao de modelos, provadores de teoremas e solucionadores de restries esto sendo empregadas para tolerar falhas. Verificao de Modelos Verificadores de modelos recebem como entrada um modelo formal do sistema, normalmente concebido por meio de mquinas de estado ou de sistemas de transio de estados, e verifica-se usando linguagens provenientes da lgica temporal, as propriedades a serem satisfeitas (Bernardeschi et al, 2002). Todas as tcnicas de verificao de modelos so suportadas por ferramentas, o que facilita a sua aplicao, as quais detectam a violao 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 verificao de modelos, normalmente, requer a especificao dos comportamentos normais, dos comportamentos de falha e procedimentos de falha e recuperao. Assim, os sistemas tolerantes a falhas so submetidos a uma exploso de estados (Bruns e Sutherland, 1997). Este problema preocupa os pesquisadores e pode diminui a oportunidade de utilizao da tcnica, outra preocupao quando os sistemas de verificao no consideram os comportamentos excepcionais dos sistemas (Romanovsky et al, 2010).
Vrias abordagens tm sido propostas nos ltimos anos focando na verificao de modelos em sistemas tolerantes a falhas. Uma abordagem que pode ser utilizada para evitar o problema de exploso estado a tcnica de verificar um modelo parcial apresentado em (Huth e Pradhan, 2003), esta tcnica tenta remover gradualmente partes do sistema e pode ser aplicada tambm com sucesso para anlise de segurana em sistemas tolerantes a falhas como em (Gnesi et al, 2003). Outra tcnica relevante para verificao e validao de modelos explorada em (Silva, 2011), a pesquisa exibe processos, ferramentas e tcnicas para a verificao e validao de modelos desde a especificao de requisitos at o cdigo-fonte. Utiliza-se de geraes automticas de modelos para evitar a incidncia de erros manuais, onde foi construdo um arcabouo arquitetural que contempla a verificao e validao 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 inferncia e exige de uma pessoa que se estabelea 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 utilizao de linguagens e simbolismos (e.g. lgica e clculo proposicional) (Romanovsky et al, 2010). O PVS (Prototype Verification System) um ambiente de verificao automtica que utiliza especificaes e uma linguagem para deduo de teoremas. O estudo utilizou uma variedade de programas construdos em linguagens funcionais e de tempo real para avaliar a tolerncia a falhas em estudos de casos (Owre et al, 1996). Outro estudo do PVS demonstrou a preocupao com o desenvolvimento de especificaes e verificaes formais para arquiteturas tolerantes a falhas, algoritmos e implementaes de um modelo de uma plataforma de computao confivel para sistemas crticos de controle de aeronaves (Owre et al,1995). Em (Kljaich et al, 1989) apresentado outro sistema de verificao formal que utiliza tcnicas de raciocnio lgico automatizado para validar tolerncia a falhas usando uma representao da rede de Petri, onde foi implementado como parte do sistema, um provador de teoremas baseado em regras para manipulao de lgica de descries dos sistema. Outras pesquisas tambm utilizaram a abordagem em conjunto com as tcnicas de verificao de modelos para tolerar falhas em sistemas crticos, a exemplo dos sistemas multi-agentes (Kummar et al, 2000) e sistemas de superviso industrial (Silva e Barreto, 2008) e o PVS (Owre et al, 1996). Solucionadores de Restries Dada uma frmula usando uma linguagem, expressa em uma lgica adequada, os solucionadores de restrio tentam encontrar um modelo que satisfaa uma condio verdadeira (Romanovsky et al, 2010). Uma dos solucionadores de restries mais famosos o Alloy (Jackson, 2002), que baseado na lgica de primeira ordem. Em (Filho et al, 2006) os autores propuseram uma abordagem que explora a relao entre a modelagem e a verificao formal tolerantes a falhas em sistemas distribudos, mais precisamente, em sistemas que usam a manipulao de exceo como mecanismo para tolerar falhas. Outra pesquisa considerou o uso de transaes atmicas coordenadas (Xu et al, 1995), onde o mecanismo construdo para tolerar falhas utiliza a manipulao de exceo em programao concorrente e unifica as caractersticas de dois conceitos complementares: conversao e transao. A conversao (Randell, 1975) uma tcnica de tolerncia a falhas que promove a recuperao de erros coordenada por um conjunto
de participantes, so projetados para interagir uns com os outros para prestar um servio especfico de recuperao (e.g. concorrncia cooperativa), enquanto a transao promove tolerncia aos erros por atomicidade quando da ocorrncia de excees (Schlichting et al, 1983).
V.IV - Teste e Depurao

Teste de software e tolerncia a falhas so as duas tcnicas principais para o desenvolvimento de um software confivel (Luy et al, 2003), sendo a principal tcnica de remoo de defeitos atualmente (Romanovsky et al, 2010). O teste refere-se verificao dinmica do comportamento de um sistema baseado em observao de um conjunto selecionado de execues controladas do sistema, ou casos de teste. Embora o teste seja largamente utilizado, quando os erros so encontrados nos casos de teste, as falhas no podem ser corrigidas imediatamente aps detectadas. Geralmente, cada falha encontrada depurada, por conseguinte, possvel localizar o ponto o qual ela foi gerada. Uma das primeiras pesquisas sobre depurao de sistemas foi apresentada em (Jacoby e Layton, 1961), 51 anos depois, diversos estudos buscam aumentar a confiabilidade dos sistemas atravs da aplicao conjunta das tcnicas de teste e depurao. Em (Durelli et al, 2011) foi realizado um estudo sobre a diversidade de aplicaes da tcnica de teste de software no mbito da engenharia de software nos 25 anos de existncia do Simpsio Brasileiro de Engenharia de Software (SBES). De acordo com o estudo, possvel notar que as aplicaes mais comuns, em 23 anos de pesquisa (Figura 6), referem-se s tcnicas de teste funcional, teste estrutural e teste de mutao. Pode-se notar tambm que os testes estruturais so os mais pesquisados e os autores explicam que a motivao em explorar esse tipo de teste deve-se ao fato que quase metade dos estudos so baseados em cdigo-fonte e a tcnica j est consolidada na academia. No entanto, o teste de mutao tambm tem uma presena constante e, recentemente, a explorao de testes funcionais conquistou alguma ateno dos pesquisadores (Durelli et al, 2011).
Figura 6 Diversidade de Aplicaes da Tcnica de Teste de Software (Durelli et al, 2011).
Um grande nmero de modelos tm sido propostos para analisar a confiabilidade de uma aplicao com base nos dados de falhas recolhidos durante a fase de testes, em (Gokhale et al, 2006) prope uma forma de incorporar as atividades de depurao analisando um modelo de crescimento da confiabilidade de sistemas de software. Outro estudos recentes, sobre a aplicao da tcnica de depurao para aumentar a confiabilidade de sistemas atravs de modelos estatsticos, podem ser vistos em (Pham et al, 1999) e (Wong et al, 2008). Por outro lado, a utilizao de modelos matemticos
pode no ser to realstico na prtica, porque o tempo para remover uma falha detectada depende da sua complexidade, habilidade e experincia do desenvolvedor, tcnicas e assim por diante (Huang et al, 2006). Outra pesquisa recente demonstra atravs de um estudo emprico, a primeira experincia sobre o aspecto da composio e reduo da suite de testes, analisando o impacto da reduo dos casos de teste sob o ponto de vista da eficcia da tcnica para localizao 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 produo do software (Romanovsky et al, 2010). Uma especificao de arquitetura representa o ciclo de vida completo de sistema e fornece, em um alto nvel de abstraes, o entendimento necessrio sobre os comportamentos dos componentes e das suas interaes (conectores), alm de uma descrio da estrutura esttica do sistema (Perry e Wolf, 1992). Uma arquitetura de software pode ser especificada usando caixas (conceitos), linhas (associaes entre os conceitos) e notaes (restries). Algumas linguagens formais podem ser utilizadas para descrio completa da arquitetura (ADLs) ou semiformais (Silva e Barreto, 2008) baseadas em notaes da UML (Unified Modeling Language) (Booch, Jacobson e Rumbaugh, 1999). No que diz respeito especificao de uma arquitetura tolerante a falhas, a preocupao est vigente em ambas as notaes. As abordagens propostas em (Garlan, 2003), (Filho, et al, 2003) e (Filho et al, 2005) so exemplos de especificaes formais para arquiteturas, onde so utilizadas linguagens de descrio 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 notaes e criando novos perfis para especificar os requisitos em sistemas tolerantes a falhas. Ainda sobre a linguagem UML, diversas abordagens propem solues atravs das transformaes de modelos. O projeto ESPRIT HIDE (Bondavalli et al, 2001) visa criao de um ambiente integrado para a concepo e verificao de sistemas confiveis e modelados em UML. Em (Silva e Barreto, 2008) os autores propem transformaes automticas a partir das suas especificaes e (Bondavalli et al, 1999) amplia abordagem para tomada de decises com informaes relevantes sobre os modelos derivados a partir da linguagem (e.g. taxa de ocorrncia de falhas, percentual de faltas permanentes). Uma abordagem modular e hierrquica para arquiteturas de software confiveis 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 especificao das suas partes crticas. Em (Pai e Dugan, 2002) os autores utilizam os modelos descritos em UML usando rvores de falhas dinmicas, onde a UML usada como uma linguagem para descrever a substituio do mdulo e propagao de erros. Em (Ferreira et al, 2011) a linguagem UML tambm foi utilizada para analisar o fluxo de excees utilizando diagramas de atividades. Um modelo de especificao de uma arquitetura, geralmente, constitui apenas o comportamento normal do sistema, como consequncia, o sistema pode falhar de maneira inesperada devido ao funcionamento anormal que no foi modelado. No mbito dos sistemas de crticos com requisitos estritos de funcionamento, torna-se necessrio introduzir tolerncia a falhas nos nveis das abstraes propostas pela da arquitetura.
Essa ao pode melhorar a eficcia da recuperao de erros e reduzir drasticamente a quantidade de falhas na entrega final do software aps todo o seu ciclo de desenvolvimento (Kienzle, 2008). Muitas abordagens tm sido propostas para a melhoria da anlise e modelagem de arquiteturas tolerantes a falhas, uma pesquisa abrangente sobre esse tema est descrito em (Sozer, 2009). Falha de especificao de arquiteturas tolerantes a falhas tambm podem ser encontrados em muitos trabalhos como em: (Medvidovic e Taylor, 2000), (Medvidovic et al, 2002) e (Garlan, 2003). As tcnicas de anlise para tolerar falhas da arquitetura (e.g. deteco de concorrncia, testes, verificao, simulao, desempenho) permitem que os engenheiros de software possam avaliar a sua qualidade em relao aos seus requisitos. Algumas abordagens foram propostas para anlise de falhas, onde a maioria apresenta abordagens para verificao da conformidade do modelo de arquitetura em relao aos requisitos para tolerar as falhas e suas limitaes (Filho et al, 2005,) e (Lemos, 2006). Outro estudo apresentou a juno da tcnica de teste para verificar arquiteturas tolerantes a falhas (Brito et al, 2005). A fase de projeto ou design tambm insere diversas informaes coletadas para especificao da arquitetura de implementao e produz diversos artefatos a serem utilizados pelos desenvolvedores para orientar e documentar a codificao do software. Ao lidar com sistemas tolerantes a falhas, a fase de projeto precisa de algumas ferramentas para modelagem do domnio da aplicao, alm de metodologias especficas para conduzir as tcnicas de tolerncia a falhas. Em (Beder et al, 2001) e (Garcia e Rubira, 2001) duas abordagens so apresentadas para facilitar essa prtica criando padres de tolerncia 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 especificao de uma ao coordenada atmica, gerado automaticamente o cdigo 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 especificao de tolerncia a falhas e anlise durante o processo de desenvolvimento proposto. considerada a abrangncia da especificao de requisitos normais e excepcionais, alm de como usar essas informaes para especificar os componentes durante a fase de projeto de software e, posteriormente, a sua implementao. Em (Brito et al, 2005) apresentada uma estratgia semelhante, onde adotado um processo de especificao de componentes usando a linguagem UML para testes de software. Tambm importante mencionar que dependendo da implementao da arquitetura pode ser mais fcil ou difcil implementar as tcnicas de tolerncia a falhas. Alguns estudos propuseram padres, porm certos padres so mais adequados que outros. Em (Harrison e Avgeriou, 2008) foi feita uma avaliao sobre quais padres arquiteturais podem ajudar a tornar os sistemas mais confiveis. Estilos arquiteturais e middlewares tambm podem promover tolerncia 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 restries locais ou globais sobre a forma que a composio ser feita. Um middleware pode ser usado para implementar um estilo arquitetural ou conectores, atravs de diversas polticas (e.g. coordenao, persistncia, segurana) (Romanovsky et al, 2010). Por isso, a tolerncia a falhas no seu suporte tambm necessitou ser investigada. Uma abordagem para tolerar falhas usando a tecnologia de middleware foi idealizada em (Issarny e Bantre, 2001). A partir do aumento do seu uso, diversos middlewares foram pesquisados, a exemplo do
CORBA, onde muitas se referem ao tratamento de excees como em (Issarny e Bantre, 2001) e (Feng, et al, 2005). Outros mtodos de tolerncia a falhas nos middlewares tambm foram investigados a exemplo de (Bondavalli, et al, 2004). J as propostas utilizando estilos arquiteturais podem ser vistas em alguns trabalhos, desde a idia 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 EXCEES

John Goodenough (Goodenough, 1975) foi o primeiro a definir os conceitos envolvendo tratamento e manipulao de excees, suas tcnicas e aplicaes. Ele definiu uma exceo como: uma condio detectada durante a tentativa de executar alguma operao, que so levadas ao conhecimento do solicitante para que este seja questionado a responder, ocasionando uma condio excepcional ateno de um tratador para realizar o seu tratamento e/ou manipulao adequadamente. Desde a sua primeira apario na dcada de 1970, o tratamento de excees usando linguagens de programao no mudou muito. Os mecanismos de manipulao das situaes excepcionais, obviamente, diferem na especificao das excees e seus tratadores, alm da forma de prosseguir com o fluxo de controle em um sistema aps a falha. No entanto, essas diferenas so insignificantes diante dos modelos que contam com os mesmos princpios tradicionais de recuperao de erros e o apoio a separao explcita entre comportamentos normais e excepcionais (Garcia, Romanovsky e Issamy, 2010). Na prxima seo sero apresentados maiores detalhes sobre a evoluo do tratamento e recuperao de erros atravs de mecanismos de tratamento de exceo nas linguagens de programao. Nos anos seguintes, diversas pesquisas foram debatidas em peridicos dedicados manipulao e tratamento de exceo (Romanovsky et al, 2001) e o resultado foi a definio de uma agenda de pesquisa para os prximos anos, o que estimulou o crescimento da comunidade cientfica e o interesse em questes relacionadas com o tratamento de excees. Infelizmente, ficou claro que muitas falhas so causadas por solues incompletas ou inadequadas dessas situaes anormais. Dessa forma, h uma necessidade primordial em conhecer os benefcios e desvantagens do tratamento de exceo em projetos reais de software (Garcia, Romanovsky e Issamy, 2010) e este estudo ir promover uma viso particular desses avanos combinados com as prticas e tcnicas emergentes da engenharia de software.
VI.I - Anlise, Manuteno e Teste de Software

Tcnicas de anlise, como o controle de fluxo e fluxo de dados so usadas em uma variedade de tarefas de manuteno de software. Ao serem aplicadas com suporte s atividades de programao, estas tcnicas podem explicar a causa quando da ocorrncia de excees e a forma de construo dos seus tratadores. Muitos trabalhos apresentam abordagens que utilizam essas tcnicas 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 anlise dos efeitos das construes de tratamento de exceo nos fluxos de controle de programas Java, onde so criados grficos para o controle de fluxo de mtodos e tambm discute outras tcnicas, como teste estrutural e de regresso, que podem se beneficiar das construes de tratadores de exceo em tarefas de manuteno. Outro trabalho possui tambm o foco na anlise de propagao das excees em arquiteturas orientadas a servios,
inclusive enfatiza que o tratamento e diagnstico inapropriado, atravs desses mecanismos, pode ser um dos principais fatores que afeta o desempenho de aplicaes que utilizam os servios web (Gorbenko et al 2008). Alm de analisar o fluxo de excees, outras abordagens tambm foram propostas para descrever suas construes de uma perspectiva modular. O modelo EJFlow, possibilita compreender os fluxos de exceo a partir de uma perspectiva fim-a-fim, com o foco em um nico mdulo do programa. Alm disso, promove uma extenso dos seus mecanismos para a linguagem de programao AspectJ com o objetivo de promover robustez e modularizao (Cacho et al, 2008). Outra ferramenta para melhorar a compreenso do fluxo de excees em programas que utilizam a linguagem de programao Java apresentada em (Shah et al, 2008). Nesse estudo, para entender as necessidades de visualizao, foi realizado um experimento com um grupo de desenvolvedores de software e a ferramenta ENHACE apresenta informaes com base em trs perspectivas: quantitativa, fluxo de controle e contextual, fornecendo uma viso nos nveis de pacote, classe e mtodo com diversas abstraes. Em (Chang et al, 2002) outra ferramenta foi construda para realizar uma anlise esttica que estima os caminhos de propagao de uma exceo em programas Java. Foi construdo um grfico de propagao a partir da anlise esttica, que inclui a origem das excees, tratador e forma de propagao. A ferramenta de visualizao permite guiar os programadores na construo dos tratadores sugerindo os locais adequados a partir do rastreamento e sua propagao. Em (Ogasawara et al, 2006) foi apresentada uma tcnica para otimizar o fluxo de excees durante a execuo intensiva de programas Java. A tcnica permite registrar os caminhos dos fluxos excees em um repositrio enquanto apresenta diversas estatsticas sob as vrias categorias de programas. O estudo permitiu analisar os dados para conhecer quais programas lanavam muitas excees e os que menos suportaram a alta sobrecarga para o seu tratamento. Alguns anos aps a clarificao das propriedades e fundamentos para o tratamento de exceo apresentados por John Goodenough (Goodenough, 1975), diversos estudos j demonstravam a preocupao dessa nova viso 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 presena dessas construes no bloco de cdigo dos tratadores introduz novos elementos estruturais, tais como controle de fluxo de caminhos (Seo IV) em um programa. Para testar adequadamente tais programas, estes novos elementos estruturais devem ser considerados na sua cobertura durante o teste estrutural. Alm de prover suporte a visualizao do fluxo de excees, Sinha e Harrold (Sinha e Harrold, 2000) tambm discutiu outras aplicaes para suporte ao teste estrutural e seleo de testes de regresso dentro das tarefas de manuteno de software. Em outro estudo os mesmos autores definem os critrios a serem utilizados para testar situaes excepcionais e gerar casos de testes com base na tcnica de controle de fluxo. Tambm a representao precisa dos fluxos de excees nos programas, usando grficos para poder representar o fluxo de controle implcito das excees e o caminho de sua propagao nos sistemas (Jiang et al, 2007). Weimer e Buse (Weimer e Buse, 2008) construram uma ferramenta totalmente automatizada que estaticamente infere e caracteriza as condies que causam uma exceo em programas que utilizam a linguagem de programao Java. Alm disso, uma metodologia para a aplicao de critrios em testes unitrios e de integrao, que contm cdigo para tratamento de excees pode ser visto em (Sinha e Harrold, 1999). Outras tcnicas para validar a construo de programas com tratamento explcito de excees atravs de estudos
empricos, alm de (Sinha e Harrold, 2000), tambm sero apresentadas adiante nesta seo. A dificuldade em gerar dados para teste de excees tambm foi explorada e na literatura existem diversos trabalhos que apresentam tcnicas para gerao automtica desses dados, como em (Tracey et al, 1999). Outras abordagens buscaram facilitar o teste de situaes excepcionais utilizando anlise esttica (Robillard e Murphy, 2003) e teste estrutural automtico baseado nas falhas encontradas (Jiang et al, 2005). Com os avanos das tecnologias para a Internet, outros estudos apresentam tcnicas para o tratamento de excees em sistemas Web (Brambrilla et al, 2005) e arquitetura orientada servio (Gorbenko et al 2008), alm de prticas como a modelagem de processos (Lerner et al, 2010).
VI.II - Arquitetura, Design e Especificao de Software

A separao de interesses um dos objetivos fundamentais do tratamento de exceo, 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 separao de preocupaes tambm importante para gerenciar as variabilidades de um software relacionando estratgias de manipulao diferentes. Uma possibilidade de soluo a separao desses comportamentos em linhas de produtos de software direcionando-os para componentes especficos (Bertoncello et al, 2008). Em (Issarny e Bantre, 2001) foi realizada uma anlise das descries arquiteturais de um domnio de software e foi proposta uma linguagem de descrio arquitetural para mapeamento e construo de tratadores de excees em arquiteturas de desenvolvimento de software. Outro problema tpico encontrado em uma arquitetura como realizar o tratamento de excees independente de uma linguagem de programao. Essa soluo poderia reduzir a complexidade durante a implementao desses mecanismos e, entre outras vantagens, aumentar o reuso dos tratadores. Um estudo apresentou uma arquitetura genrica para incorporar o tratamento de excees em sistemas orientados a objetos que integra tanto o tratamento de excees concorrentes quanto as sequenciais (Garcia et al, 2000). Segundo (Nehmer e Reuter, 2008) os mecanismos atuais de tratamento de excees so insuficientes para cumprir os requisitos de confiabilidade em sistemas grandes e complexos. Por isso, os autores apresentaram um framework para o tratamento de excees como uma ferramenta de suporte aos desenvolvedores. Com base na anlise do fluxo de exceo uma falha, a abordagem promove a conteno das excees, restringindo o seu impacto global nos sistemas. Em (Fu e Ryder, 2007) tambm foram demonstrados avanos para tratar excees em grandes sistemas, onde foi adotada uma tcnica para anlise das excees que so relanadas na arquitetura de servidores de aplicao. Outra abordagem pensar nos mecanismos de tratamento da exceo aliados tcnica de replicao de dados para aumentar a confiabilidade dos sistemas. Onde a manipulao da exceo ajuda os programadores a controlar as situaes em que o fluxo normal de execuo de um programa no pode continuar, enquanto a replicao gerencia as falhas do sistema. Entretanto a manipulao das excees e a tcnica de replicao podem no se aplicar para as mesmas situaes e, portanto, a necessidade de um estudo aprofundado para conhecer os benefcios e limites dessa abordagem pode ajudar na explorao benfica dessas tcnicas. Em (Dony et al, 2008) uma especificao para execuo de um sistema de tratamento de exceo para middlewares com suporte a
sistemas multi-agentes foi proposta com a combinao do tratamento de exceo e a tcnica de replicao, tornando os agentes mais confiveis.
VI.III Estudos Empricos

Construir componentes de forma a separar situaes normais das excepcionais, alm de promover o reuso dos tratadores de exceo, foi tema de diversos estudos para avaliar aproximaes similares s apresentadas nas subsees anteriores. Muitos estudos demonstraram mtricas para tentar explicar porque a tcnica de tratamento de exceo possui determinadas limitaes. As pesquisas avaliam diversos aspectos em aplicaes reais para entender como a tcnica de tratamento de exceo empregada pelos programadores, incluindo a qualidade cdigo de implementao em uma variedade de linguagens de programao. Aps investigar 32 aplicaes construdas usando as linguagens de programao Java e .Net (Cabral e Marques, 2007) concluram que as excees no esto sendo utilizadas corretamente como um mecanismo de recuperao de erro e os tratadores no so suficientemente especializados para permitir a recuperao adequada. Outro estudo avaliou a implementao de tratadores em diversas linguagens de programao orientadas a objeto e uma taxonomia foi desenvolvida para ajudar a enderear 10 aspectos tcnicos durante a construo dos tratadores de exceo, sua representao em tempo de design e durante a codificao 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 notificao de mensagens) dentro das aplicaes. Um estudo explorou tambm 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 cdigo da aplicao (Cacho et al, 2009). A construo de tratadores de exceo usando uma linguagem de programao orientada a aspectos (e.g. AspectJ) pode reduzir drasticamente as pores de cdigo relacionadas com a deteco 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 programao orientada a aspectos pode levar a cenrios propensos a erros. Por conta dos aspectos estenderem ou substiturem funcionalidades existentes, isso pode levar as novas excees que no foram previstas em tempo de design, incorrendo em formas inesperadas de execuo de um programa. Um estudo procurou avaliar o quanto os aspectos interferem no fluxo de controle das aplicaes ocasionando erros e criou um catlogo de padres para os erros de implementao encontrados (Coelho et al, 2008). Um novo estudo (Hoffman e Eugster, 2008) revelou que, aps reconstruir os tratadores de exceo em trs aplicaes reais, a abordagem proposta pelos autores permitiu melhorar a modularizao das situaes anormais utilizando pontos de juno explcitos com a linguagem AspectJ. Neste estudo, outros avanos utilizando essa abordagem sero apresentados adiante (Seo VIII).
VII. TRATAMENTO DE EXCEES USANDO LINGUAGENS DE PROGRAMAO

As excees so recursos adicionados s linguagens de programao para fornecer ao programador a capacidade de especificar o que deve acontecer quando condies
incomuns durante a execuo de um programa ocorrer, mesmo com pouca frequncia. Originalmente, em linguagens de programao, tais condies atpicas apenas eram repassadas para controle dos sistemas operacionais que, em seguida, abortavam a execuo do programa forosamente. Porm, quando tais condies, embora raras, pudessem ser antecipadas, o programador poderia escrever algum cdigo para reagir a elas e, graciosamente, lidar com as excees. Excees e cdigos para manipul-las um mecanismo previsto pelas linguagens modernas para contornar esse problema (Ryder, Soffa e Burnett, 2005). A insero de mecanismos para o tratamento excees em linguagens de programao est atrelada as necessidades de confiabilidade e deteco de falhas em engenharia de software (Seo V). A linguagem precursora no suporte ao tratamento de excees foi a Lisp, em meados dos anos 50. Aps, a PL/I, uma linguagem de programao desenvolvida pela IBM e sua comunidade de usurios para o Sistema 360 em meados dos anos 60, incluiu algumas facilidades para lidar com o controle de fluxo atpico em uma linguagem de alto nvel. Oferecendo suporte aos programadores para lidar com algumas condies excepcionais, tais como: final de arquivo, overflow e corrupo dos dados. Em meados dos anos 1970, a confiabilidade dos sistemas era uma preocupao muito forte entre os pesquisadores de engenharia de software e linguagens de programao. Em maro de 1977, as conferncias: SIGPLAN, SIGOPS e SIGSOFT, alm do peridico Comunications of The ACM, apresentou uma edio especial sobre linguagem para o design de software confivel em agosto de 1977. Assim, os mecanismos para o tratamento de exceo, nas diversas linguagens conhecidas hoje, foram influenciados pela pesquisa em engenharia de software (Ryder, Soffa e Burnett, 2005). No mesmo peridico, alguns meses depois, John B. Goodenough (Goodenough, 1975) apresentava diversas questes para o tratamento de exceo, classificando alguns tipos de utilizao para lidar com o domnio ou o intervalo de falha em uma operao, indicar a importncia de um resultado ou permitir monitorar uma operao (Ryder, Soffa e Burnett, 2005). Alm das contribuies de Goodenough, neste mesmo ano, Brian Randell (Randell, 1975) descreveu sua prpria construo para deteco e recuperao de erros. Ele definiu um mecanismo estruturado chamado blocos de recuperao, que poderia ser usado quando uma falha inesperada ocorresse. Aps alguns anos, diversos estudos investigaram a possibilidade de unir as abordagens de blocos de recuperao e tratamento de exceo para coexistir no mesmo cdigo a exemplo do estudo de Flaviu Cristian (Cristian, 1982). Perry, em seu artigo premiado no ICSE (Perry, 1989), discutiu a especificao e manipulao das excees como parte de um ambiente integrado de desenvolvimento (IDE), quando sistemas de grande porte so construdos 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 especificaes de interfaces de um mdulo incluam descries para especificar as excees a serem manipuladas nos sistemas, alm de estratgias para o seu tratamento. Sua ferramenta verificava quais excees eram tratadas de acordo com a especificao na interface e o seu estudo demonstrou que o tratamento de excees em linguagens de programao no final dos anos 80 influenciou bastante a pesquisa na rea de engenharia de software no projeto de novos IDEs.
O tratamento de excees foi um grande tema de debate na dcada de 90 na conferncia USENIX C++, onde Koenig e Stroustrup (Koenig e Stroustrup, 1993) apresentaram um modelo para tratamento de excees orientado a objetos. Os comandos so executados dentro de um bloco try, que por sua vez, tem associado os blocos catch, que manipulam as excees. Este projeto foi influenciado pelo trabalho de Randall (Randall,1975), segundo pesquisadores (Ryder, Soffa e Burnett, 2005). As excees, possivelmente acionadas por uma funo ou operao de forma direta ou indireta, podem ser listadas como parte da declarao da funo e as violaes desta especificao so tratadas em tempo de execuo, no em tempo de compilao, como na linguagem Java. Esta deciso foi em parte devido s restries da linguagem C, onde as funes no tinham nenhuma construo explcita para o tratamento de exceo. Quando uma funo com uma especificao de exceo lana uma exceo que no est na sua lista, ento a funo void unexpected() chamada e sua execuo geralmente interrompida (Ryder, Soffa e Burnett, 2005). Assim, diversas pesquisas envolvendo o tratamento de exceo em linguagens orientadas a objetos vieram aps 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 programao orientada a aspectos descreve o tratamento de excees como uma das preocupaes transversais em um programa orientado a objeto. Esta abordagem foi apresentada por Kiczales (Kiczales et al,1997) e expressa a deteco e o tratamento de excees (Lippert e Lopes, 2000) para diminuir a quantidade de cdigo redundante em um programa. A linguagem AspectJ permite criar crosscuts abstratos que podem ser instanciados em muitos locais diferentes, onde a manipulao das excees exige o mesmo tratamento. No estudo de caso apresentado por Lippert e Lopes, utilizando uma aplicao Java contendo 750 classes de domnio e 150 de teste, os autores reduziram as linhas de cdigo que continham tratamento de excees de 10,9% para 2,9%. Isto representou uma reduo significativa sobre o tamanho original do programa e inspirou centenas de trabalhos nos ltimos anos.
VIII. O TRATAMENTO DE EXCEO NO DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS (2009-2012)

O emprego das prticas de engenharia de software no tratamento de excees, principalmente em linguagens de programao modernas, tem contribudo muito para aumentar a tolerncias a falhas residuais de softwares e este estudo procurou conhecer os avanos no mbito do desenvolvimento de software orientado a aspectos nos ltimos anos. Na ltima dcada 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 prticas de engenharia de software e aumentando o retorno dos investimentos neste mbito. Vrios frameworks orientados a aspectos surgiram (e.g. AspectJ, JBoss e Spring) em grandes projetos na indstria, onde o mais proeminente o servidor de aplicaes da IBM, o WebSphere (Rashid et al, 2010). Um dos maiores problemas com a tcnica de POA o fato dos aspectos estenderem ou substiturem funcionalidades existentes durante a execuo de um programa, tal ao pode aumentar o surgimento de novas excees, que podem ser lanadas e propagadas de forma inesperada na pilha de execuo do programa. E essa ao, diminui a confiabilidade dos sistemas, porque as excees no foram previstas em tempo de
design e possivelmente no sero tratadas adequadamente. Adams e Schutter propuseram uma abordagem chamada Aspicere2. A soluo fornece melhorias no mecanismo de tratamento de exceo monitorando a propagao de erros, log, limpeza de recursos e ainda permite substituir aspectos por outros baseados em um cdigo de recuperao. A Aspicere2 torna os aspectos mais robustos e tolerantes evoluo do cdigo da aplicao segundo os autores, porm no resolve definitivamente o problema (Adams e Schutter, 2007). Algumas pesquisas destacaram avanos no tratamento de excees utilizando a linguagem AspectJ, uma extenso da linguagem de programao Java, que a mais utilizada nessas pesquisas. Muitas delas esto concentradas nas prticas de anlise e teste, alm de arquitetura, especificao e design de software. Por isso, o estudo far uma apresentao 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, atravs da tcnica de tratamento de excees.
VIII.I - Anlise e Teste de Software

Assegurar a confiabilidade do cdigo que implementa o tratamento de exceo em DSOA uma tarefa desafiadora. O prprio teste do cdigo j difcil, uma vez que complicado lanar todas as excees possveis durante os experimentos e o grande nmero de diferentes excees poderia levar um sistema a infinitos casos de testes. Alm disso, observou-se que algumas propriedades da POA podem entrar em conflito com as caractersticas dos mecanismos de tratamento de exceo, agravando os problemas existentes (Coelho et al, 2011). Por isso, a anlise e verificao do cdigo de tratamento de exceo estimularam diversas pesquisas. Em uma pesquisa muito recente (Coelho et al, 2011) apresentada uma abordagem que utiliza uma ferramenta de anlise esttica chamada SAFE. O objetivo verificar a confiabilidade do cdigo de tratamento de excees em programas que utilizam a linguagem AspectJ. O estudo avaliou a eficcia e a viabilidade da abordagem de duas maneiras: (i) investigando se a ferramenta SAFE suficientemente precisa para descobrir informaes do fluxo de exceo e (ii) utilizando a abordagem em trs sistemas de tamanho mdio com diferentes domnios de aplicao para comparar os resultados. O estudo ainda indica que mais barato verificar a conformidade do tratamento de exceo estaticamente, com base em uma especificao, que criar diversos casos de teste para procurar todas as excees possveis. No entanto, um comportamento especfico dos tratadores de exceo, que o cdigo de recuperao acionado aps uma exceo ser capturada, funcionou corretamente, porm, essa ao geralmente no pode ser verificada usando anlise esttica, j que as excees ocorrem em tempo de execuo de um programa (Goodenough, 1975). Dessa forma, a anlise esttica pode ser mais benfica para avaliar os possveis fluxos de excees, assim como em diversos estudos em que a abordagem utilizada para verificar a assertividade dos requisitos de um software e promover a melhoria do cdigo atravs da tcnica de inspeo utilizando analisadores automticos (Seo VI). As informaes de relacionamento entre classes de um domnio de aplicao a base para construo de um fluxo de excees em linguagens orientadas a objeto, onde o objetivo melhorar o entendimento desses fluxos e possui diversos benefcios (e.g. evitar cdigo redundante, padronizao do cdigo). De acordo com os tipos de relaes entre as classes (e.g. herana, agregao e associao) a construo de um grfico de
fluxo de controle feito de forma incremental e essa tarefa exige um algoritmo eficiente, pois em sistemas grandes a construo desse grfico pode ser fastienta e tediosa. Alm de um algoritmo otimizado, necessrio melhorar a preciso para se evitar redundncias desses relacionamentos, o que dificultaria o entendimento dos fluxos de excees. Zhang et al. (Zhang, Jiang, Li e Yuan, 2009) propem um algoritmo usando o conceito de program slicing para construir essas relaes de dependncia em softwares que utilizam classes para o tratamento de excees, melhorando a sua preciso em relao aos estudos anteriores (Seo VI). Geralmente, o processo de se levantar uma exceo est intimamente relacionado com a sua manipulao. Em sistemas complexos, o ponto em que so levantadas e o da sua manipulao no esto necessariamente em um mesmo local (e.g. mtodo, classe ou pacote) (Qiu, Zhang e Lian, 2010). Em uma aplicao Java, por exemplo, uma exceo pode fluir atravs de diversos mtodos em um sistema, inclusive atravs de frameworks e sua mquina virtual (Coelho et al, 2011). Portanto, o mecanismo para o seu tratamento possui alguns problemas significativos quando se pretende levantar uma exceo: (i) como identificar os manipuladores? (ii) como identificar os componentes dependentes durante o tratamento das excees? e (iii) como prever quais componentes sero afetados? Quando uma exceo lanada, o fluxo de controle busca o cdigo para o seu tratamento com o objetivo de responder adequadamente e tentar a recuperao do erro, por isso a sua propagao necessria. Para os desenvolvedores, a propagao de uma exceo ultrapassa a fronteira dos componentes por meio de sua pilha de chamadas. Assim, a dificuldade para identificar em qual ponto a exceo surgiu e onde deve ser manipulada aumentada por causa da sua propagao. O que eleva o custo de manuteno do software (Qiu, Zhang e Lian, 2010). Analisando a dependncia dos mtodos, Qiu, Zhang e Lian associaram cada mtodo com os tipos de exceo, pela relao de lanamento ou captura declarada explicitamente na sua assinatura e apresentaram um grfico de propagao dessa dependncia. Atravs do cdigo Java compilado, o algoritmo extraiu as informaes de dependncia dos mtodos e distinguiu quais mtodos lanavam ou capturavam as excees, alm dos seus tipos. Em seguida, efetuou a anlise do caminho de propagao das excees e a sua estrutura de propagao em cinco softwares durante um estudo de caso. Eles tambm incluram uma anlise da hierarquia das excees e a fronteira entre as reas onde os mtodos forneciam os mecanismos para o seu lanamento e manipulao. Promovendo uma grande melhoria na anlise do fluxo de propagao das excees em relao aos estudos anteriores (Seo VI). J que o tratamento de excees pode garantir a modularizao dos sistemas na presena de erros, oferecendo abstraes para representar as situaes errneas nos mdulos na forma de excees, tornou-se possvel encapsular as condies de erro em tratadores (Bernado et al, 2011). As construes de cdigo para o tratamento de excees so geralmente propensas a falhas, devido, por exemplo, falta de ateno ao longo do ciclo de desenvolvimento do software (Bernado et al, 2011). As abordagens baseadas em anlise esttica foram propostas para descobrir essas falhas, no entanto, por conta das limitaes da abordagem, combinada as caractersticas das linguagens modernas (e.g. herana e polimorfismo) a anlise esttica costuma relatar muitos falsos positivos. Assim, so necessrias etapas manuais para verificar se os caminhos detectados durante a ocorrncia de uma exceo realmente aconteceram, tornando o
processo custoso. Alm disso, vista negativamente pela limitao da abordagem somente ser utilizada para detectar as falhas e no tratar as excees (Bernando et al, 2011). Com o advento das metodologias geis, algumas abordagens tm sido utilizadas com sucesso no desenvolvimento de aplicaes modernas e so fortemente baseadas em automao de testes. No entanto, no 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 propagao das excees esto corretos em tempo de execuo. Os testes seguem uma abordagem gil e foram implementados a partir da extenso do framework JUnit. Apesar da abordagem ser promissora, ainda existem outros entraves durante a adoo da POA. Diversos estudos empricos tm demonstrado que o DSOA promove a modularizao e estabilidade na presena de interesses transversais (e.g. tratamento de excees). A estabilidade no design engloba a sustentao das propriedades do sistema e a inadvertncia dos efeitos quando das suas alteraes. Para avaliar as vrias facetas da estabilidade durante o design e modularizao de um software, um conjunto de mtricas podem ser observadas para medir: a coeso, a propagao de mudanas, anlise da interao entre os interesses e a identificao desses efeitos na arquitetura. to 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 prticos, por tornar o sistema menos resistente as falhas. Assim, a integrao dos mecanismos de tratamento de exceo, combinados com as tcnicas de modularizao levantam diversas questes (Coelho et al, 2009). Embora a POA possa ser utilizada para promover a modularidade e reutilizao de cdigo no tratamento de exceo (Lippert e Lopes, 2000) possvel observar em outros estudos que tambm pode aumentar a propenso a erros nos sistemas, ocasionando: (i) maior evidncia de excees no capturadas, quando os aspectos atuam como manipuladores de excees, levando a falhas imprevisveis no sistema e (ii) o tratamento pode ser feito de forma no intencional, quando as excees so lanadas por aspectos e capturadas de forma inesperada por existir algum tratamento no seu cdigo. Portanto, existe uma necessidade fundamental em definir procedimentos e mtricas para avaliar o impacto das tcnicas de modularizao na robustez do software. Essas mtricas podem fornecer meios de avaliar se o sistema proporciona uma resposta tolervel quando do surgimento de problemas que possam causar a sua degradao (Coelho et al, 2009). Coelho et al apresentam um framework para avaliar a robustez dos sistemas que utilizam a tcnicas de modularizao no tratamento de excees atravs de anlise esttica e dinmica, incluindo novas mtricas que no foram consideradas em estudos empricos anteriores. Alm do conjunto de mtricas, foi definida uma abordagem para suas medies utilizando a linguagem AspectJ. A transparncia (obliviousness) o ato ou o efeito de deixar algo transparente, no sentido de poder ser esquecido ou passar despercebido. Nesse contexto, a transparncia permite que os componentes no necessitem ser preparados para receber qualquer melhoria proporcionada pelos aspectos (Chavez, 2004). A transparncia tem sido uma propriedade controversa, desde as primeiras pesquisas envolvendo programao orientada a aspectos. A falta de consistncia entre os componentes e os aspectos tende a
incorrer em implementaes incorretas. Alguns estudos contradizem a intuio comum que a utilizao dos pontos de juno a principal fonte de defeitos, onde os outros mecanismos atualmente disponveis em AspectJ (e.g. pontos de juno, adendos e declaraes inter-tipo) tambm so propensos a falhas. Os mecanismos internos da POA demonstram ter uma boa indicao de falhas quando so considerados conjuntos de mdulos dentro de cada interesse da aplicao separadamente. Neste caso, o nmero de falhas associadas a um interesse pode ser diretamente proporcional ao nmero de mecanismos utilizados para implement-la. Assim, os resultados revelaram um impacto negativo da propriedade de transparncia nas falhas dos programas implementados com AspectJ (Ferrari et al, 2010). Entretanto, abordagens recentes e outras linguagens com suporte programao orientada a aspectos podem ajudar a amenizar o problema da transparncia. Alguns exemplos so as Interfaces de Programao de Interesses (XPIs) e Pontos de Juno Explcitos (EJPs) (Hoffman e Eugster, 2008). Embora elas reduzam a transparncia entre os mdulos do sistema, essas abordagens ajudam a melhorar a compreenso, tornando a interao aspecto-componente mais explcita (Ferrari et al, 2010). Quando uma situao anormal ocorre, uma exceo lanada e, em seguida, se propaga de forma dinmica atravs da pilha de chamadas em busca de um manipulador adequado. O manipulador uma parte do cdigo que executada ao receber uma exceo como parmetro. Se um manipulador no for encontrado, a exceo no capturada, e geralmente, a execuo do programa abortada. Excees tratadas usando um aspecto podem ser inadvertidamente manipuladas. Por outro lado, as excees 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 Exceo atravs de um Aspecto (Figueroa e Tanter, 2011).
Considerando o cdigo de implementao de um manipulador em AspectJ (Listagem 1), ao instanciar a classe foo e executar o mtodo getConfiguration() para definir um valor de configurao (ConfigValue), em caso de falha, um valor padro ser utilizado. O aspecto registra as informaes durante a execuo do mtodo getConfiguration(), se o objeto logger no encontrar o arquivo de log ocorrer uma falha e esta ser lanada por meio de uma exceo do tipo FileNotFoundException, que interceptada pelo manipulador implementado em AspectJ. Assim, o valor padro usado porque o aspecto falhou, mesmo nos casos em que o mtodo getConfiguration() retornaria o valor corretamente (Figueroa e Tanter, 2011). Esta situao ocorre porque o mecanismo de tratamento de exceo mescla os aspectos, os manipuladores e as excees em uma nica estrutura plana. Este problema conhecido por conflation, uma generalizao do problema de vinculao tardia (Late Binding Handler Pattern) descrito por (Coelho et al, 2008) como:
"O problema acontece quando um aspecto criado para lidar com uma exceo, mas as interceptaes do aspecto em um ponto, durante a execuo do programa em que a exceo foi capturada, j estava atrelado a um manipulador na pilha de chamada do mtodo que liga o sinalizador da exceo ao manipulador construdo no aspecto". A fuso entre os aspectos, as excees e seus manipuladores pode, inadvertidamente, desencadear a execuo de manipuladores no intencionais, mudando o comportamento esperado do programa, onde as excees so capturadas acidentalmente pelos aspectos atravs dos seus tratadores ou vice-versa. Assim, os programadores no podem ter certeza da interao desejada entre as excees, os aspectos e seus tratadores. Em (Figueroa e Tanter, 2011) foi proposta uma linguagem semntica orientada a aspectos que permite especificar os nveis execuo de um tratador de exceo, demonstrando ser uma possvel soluo para o problema de conflation. Por padro, a linguagem assegura que no haja nenhuma interao entre os aspectos, as excees e os seus tratadores e permite flexibilizar uma interao especfica entre eles quando necessrio. Outros estudos recentes tentaram avaliar os benefcios e desvantagens de se empregar a POA para modularizar o cdigo de tratamento de excees. Apesar dos muitos estudos interessantes, eles no atingiram um consenso no tocante ao impacto da POA no reuso de tratadores de excees. Inclusive, em alguns casos, os resultados desses estudos esto em contradio direta (Taveira et al, 2009). Castor et al. (Castor et al, 2009) apresentam um estudo aprofundado sobre a adequao da linguagem AspectJ para fins de modularizao e reuso do cdigo de tratamento de exceo. O estudo consistiu em refatorar o cdigo responsvel pelo tratamento de erros em aplicaes existentes para os manipuladores de exceo criados em AspectJ. Realizou uma anlise quantitativa de 5 sistemas, sendo 4 orientados a objeto e 1 orientado a aspecto, utilizando 4 atributos de qualidade: separao de interesses, acoplamento, coeso e consistncia. O estudo tambm investigou outras questes sob diversas perspectivas dos sistemas refatorados, incluindo: (i) de que forma os aspectos podem ser reutilizados para tratamento de erros, (ii) os efeitos benficos e prejudiciais dos aspectos e (iii) a escalabilidade da POA no apoio a modularizao do tratamento de exceo na presena de outros aspectos. A concluso geral do trabalho (Castor et al, 2009) que a POA no corrige design ruins, em outras palavras, sistemas orientados a objetos onde o cdigo de tratamento de exceo j est bem estruturado, a POA melhora a estrutura por separar as situaes normais das excepcionais do sistema. No entanto, para sistemas complexos ou com o cdigo de tratamento de exceo mal-estruturados, a POA piora a qualidade do sistema. O estudo tambm indica que a melhor abordagem para extrao das situaes anormais a serem implementadas nos aspectos, pensar nessa construo desde o incio, em todas as fases do desenvolvimento de software. Quando esta situao no possvel, por exemplo, em sistemas que j foram construdos, o trabalho fornece uma orientao para melhoria do design, tornado o processo de transformao do cdigo de tratamento de exceo em aspectos mais simples. Tambm, apresenta um catlogo que abrange uma gama de cenrios que pode ser utilizado por programadores iniciantes ou experientes no DSOA (Castor et al, 2009). Nesse mbito, a avaliao do impacto da modularizao das situaes excepcionais, usando tratamento de exceo em sete sistemas com a linguagem AspectJ, tambm foi
tema de outra pesquisa recente. A tarefa iniciou com a modularizao interna dos aspectos em cada aplicao e, em seguida, tentou reutilizar o cdigo para manipular as excees entre as sete aplicaes. Os resultados do estudo indicam que apenas alguns aspectos puderam ser reutilizados, embora o nvel alcanado de reuso fosse alm do esperado pelos autores e muito diferente dos estudos realizados pelo grupo em experimentos anteriores (Taveira et al, 2009).
VIII.II - Arquitetura, Especificao e Design de Software

O desafio no tratamento de situaes excepcionais aumenta constantemente com um nmero crescente de dispositivos conectados nas redes de computadores e os erros esto presentes em todas as camadas, desde os hardwares em plataformas distribudas at os componentes de software (Mercadal et al, 2010). Os componentes so geralmente construdos por terceiros e eles so independentes uns dos os outros, onde os fornecedores dos componentes no podem prever todos os usos possveis de um componente. Assim, no se pode tratar todas as excees que o componente ir gerar em diferentes sistemas (Huang et al, 2011). Alm disso, muitos sistemas so baseados em componentes e geralmente executados em algum middleware, que encapsulam diversas solues para resolver problemas comuns no desenvolvimento de software e na sua operao (e.g. gerenciamento do ciclo de vida do componente, controle de concorrncia, interoperabilidade e segurana). Uma vez que o middleware j muito complexo, tambm susceptvel a causar excees e essas excees normalmente so lanadas como erros de sistema e incapaz de serem tratadas pela aplicao (Huang et al, 2011). Tambm por conta da necessidade de mudanas nos sistemas e nos componentes de software, o cdigo que implementada o tratamento de exceo, que est embutido nos componentes, precisa ser revisto e melhorado a cada mudana, alm de ser abrangente e modular aos pontos de vista da arquitetura, proporcionando maior reuso dos componentes (Mercadal et al, 2010). Os estilos arquitetnicos tambm permitem a reutilizao das arquiteturas e aplicam com sucesso padres de design para uma classe particular de sistemas. O problema o fato dos conjuntos de juno (pointcuts) serem tipicamente usado pelas LDA-OA atuais para selecionar os pontos de juno com base nos nomes dos elementos arquitetnicos, expondo a LDA a fragilidade dos conjuntos de juno (Greenwood et al, 2007) (Kellens et al, 2006) e problemas de reutilizao (Chavez et al, 2009). Tratamento de exceo tem sido amplamente referido na literatura como uma preocupao transversal em sistemas, seguindo os diferentes tipos de design (e.g. arquiteturas em camadas e MVC). A manipulao do erro amplamente reconhecida como um problema de design e tende a afetar quase todos os mdulos essenciais dos sistemas. Desse modo, natural o entendimento sobre as excees serem de natureza arquitetnica e, neste contexto, estaro sempre associadas aos componentes e suas interfaces. Por definio, uma exceo de natureza arquitetnica se levantada dentro de um componente da arquitetura, mas no 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 juno para fornecer uma linguagem de conjuntos de juno com base na semntica dos estilos arquitetnicos. Estilo baseado em um modelo de pontos de
juno e a abordagem proposta para composio independente de linguagem e pode ser adaptvel a LDA diferentes para definir um estilo de comportamento especfico. Em outro contexto, uma linha de produtos de software (LPS) visa a melhorar o desenvolvimento e a eficincia durante a construo de uma famlia de sistemas de software de um determinado domnio de aplicao. O conceito promove a reutilizao em larga escala, atravs da arquitetura de linhas de produtos (ALP). Assim, comum a existncia de uma variedade de produtos similares em termos dos seus elementos arquitetnicos. A combinao de uma LPS e Desenvolvimento Baseado em Componentes (DBC) uma tcnica bem conhecida para conceber produtos de forma rpida e eficaz, a partir de um conjunto de artefatos reutilizveis (Tizzei et al, 2011). Nesse aspecto, o DSOA uma tcnica que apoia a modularidade e permite implementar interesses transversais, porm existem muitas evidncias que o uso dos aspectos pode levar a instabilidades nas aplicaes e alguns estudos tm combinando DSOA e LPS para estruturar a construo de artefatos atravs dos aspectos. Por isso necessrio investigar os impactos negativos e positivos que a utilizao 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 trs formas: (i) uma aplicao construda utilizando uma abordagem hbrida 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 implementao possua oito verses funcionalmente equivalentes. Foi utilizado um conjunto de mtricas para avaliar o impacto das mudanas e modularidade para medir a estabilidade da arquitetura. O experimento indicou que a abordagem hbrida foi a mais estvel na maioria das oito verses (Tizzei et al, 2011). Outras tcnicas buscaram a verificao das propriedades especificas do domnio a partir do DSOA. O Design por Contrato (DbC) uma tcnica para desenvolver e melhorar a correo funcional dos sistemas de software por meio da definio de contratos entre as classes clientes e seus fornecedores. Os contratos so aplicados durante a execuo dos sistemas e se um deles violado, ocorre um erro na aplicao. Runtime Assertations Checkers (RACs), que uma tcnica combinada a DbC, impe a verificao desses contratos em tempo de execuo da aplicao. Apesar de amplamente utilizada, os estudos mostraram que as caractersticas dos mecanismos de tratamento de excees em linguagens modernas, podem descartar as violaes de contrato detectadas pelos RACs. Como resultado, a violao de um contrato no pode ser refletida em um erro durante a execuo de um sistema, inviabilizando a abordagem de DbC. Um estudo recente apresenta uma tcnica de recuperao de erros usando RACs que adentra tais limitaes. A tcnica se baseia na POA e objetiva a extenso das funcionalidades dos RACs existentes que interrompem as violaes de contrato no momento em que seriam descartadas. A tcnica de recuperao 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 violaes contratuais de serem descartadas, independentemente das caractersticas do cdigo de manipulao de exceo do aplicativo (Reblo et al, 2011).
IX. CONCLUSO
Sistemas de software esto presentes em toda parte controlando muitos dispositivos utilizados todos os dias, incluindo os sistemas crticos, cujo tipo de aplicao no pode tolerar um mau funcionamento. Muitos sistemas falham diariamente e algumas falhas mudaram a direo das pesquisas na rea de tolerncia a falhas (Avizienis, 2001). Em 1993, um relatrio da NRC (National Research Council) apontou que 81% do total de interrupes nos sistemas foram causadas por falhas em software e a nica alternativa eficiente seria alcanar a confiabilidade incorporando os mecanismos de tolerncia 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 prticas de engenharia de software. O que significa que as tcnicas de tolerncia as falhas esto sendo utilizadas em todo o ciclo de vida do software. Desse modo, essas tcnicas, especialmente o tratamento de exceo, podem responder as necessidades atuais de confiabilidade dos sistemas de softwares. Pois o tratamento de excees, que foi muito debatido na dcada de 90 (Koenig e Stroustrup, 1993) ainda acreditado por muitos pesquisadores como uma das principais abordagens para se alcanar a confiabilidade (Romanovsky et al, 2010). Muitas linguagens possuem o suporte ao modelo de tratamento de erros proposto por Koenig e Stroustrup durante muitas dcadas e no houve mudanas desde o modelo criado por eles na dcada de 90 (Garcia, Romanovsky e Issamy, 2010). Nos ltimos anos, a integrao desses mecanismos combinados com a tecnologia de Programao Orientada a Aspectos (POA) despertaram o interesse da comunidade acadmica e levantaram diversas questes. Embora o paradigma seja utilizado para promover a modularidade e reutilizao de cdigo possvel observar em diversos estudos que o seu uso pode tornar os sistemas mais propensos a falhas. Por intermdio de estudos recentes, este trabalho discerniu sobre as reais vantagens e desvantagens no emprego de uma LOA dentro desse contexto, incluindo o tratamento das situaes excepcionais nos sistemas de software. Por limitaes da linguagem AspectJ, os estudos contradizem uns aos outros, levando at mesmo ao descrdito no alcance do reuso e a modularizao junto com a estabilidade do software, da arquitetura e dos seus componentes. Este trabalho considera que os estudos recentes na rea de tratamento de excees que utilizam uma LOA, por estar no limiar das suas prprias tcnicas, pouco exploraram dentre tantas tcnicas existentes e j consolidadas pela academia (Sees IV e V), a exemplo das prticas de Verificao e Validao de Modelos e Teste de Software Baseado em Modelos. Pesquisas emergentes como as de Silva e Barreto (2008) e Aichernig e Jobstl (2012) so promissoras por contornar alguns problemas, especialmente, a criao e correo manual de classes de falhas que tratam as situaes excepcionais, alm de permitir maior abstrao na criao dessas classes. Tais vantagens aumentariam a confiabilidade, o reuso e a modularizao desde as definies arquiteturais at o cdigo da aplicao. Por isso, o prximo passo desse projeto ser a realizao de um estudo para conhecer quais as vantagens e limitaes dessas tcnicas, atravs da conduo de um experimento. Aps, a criao de uma plataforma para derivao de casos de testes, onde os testes sero gerados considerando os modelos de classes de falhas e de domnio de aplicao.
REFERNCIAS
[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 (SPLAT07). 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 (ISORC01), Magdeburg. [9] Bernardeschi, C., Fantechi, A., Gnesi, S.. (2002) "Model Checking Fault Tolerant Systems". Software Testing Verification and Reliability, Vol. 12, Issue 4, pages 251275, 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 (WEH08). 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 Users 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-0449/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. 13771417. [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 (SCAM02). IEEE computer Society. [29] Chavez, C. V. G. (2004). Um Enfoque Baseado em Modelos para o Design Orientado a Aspectos. Tese de doutorado, Pontifcia Universidade Catlica 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., Alfrez, 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 (WEH08). 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 Its 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 AspectOriented 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, N2, 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 (WEH08).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-2757/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 CBSE11, June 2024, 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, maro. [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 Maro/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., Fernndez, L. F., Snchez, 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
[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 (ISSRE03). [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.. 219244. [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/SPLASH10, October 1721, 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 70105. [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 (ISSRE02). 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 212.
[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-SoftwareDebugging 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 Explorao dos Conceitos Bsicos de Tolerncia 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 (ISSTA08), July 2024, 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, n2, pp-19-26. [119] Reblo, 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(FTfJP11). 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 191221. [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.
[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 431477. [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) Separao e Validao de Regras de Negcios MDA usando Programao Orientada a Aspectos. II Simpsio Brasileiro de Componentes e Arquiteturas de Software, Porto Alegre. [132] Silva, J. B.. (2011) "Proposta de uma Arquitetura para o Gerenciamento de Regras de Negcio 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., Arajo, A., Amorim, J., Castor, F., Barreiros, E.. (2009) "Assesssing
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. , Assuno, 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 InterClass Control Dependence of Programs with Exception-Handling". Proceegins of the International Conference on Computational Intelligence and Software Engineering (CiSE). IEEE Computer Society. pp1-4.

Tratamento de Falhas Residuais Durante o Design de Sistemas de Software - O Estado Da Arte

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Tratamento de Falhas Residuais Durante o Design de Sistemas de Software - O Estado Da Arte

Diunggah oleh

Hak Cipta:

Format Tersedia

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

Resumo: Para garantir a confiabilidade dos sistemas de software, vrias tcnicas

II. CONCEITOS BSICOS SOBRE CONFIABILIDADE

Figura1- rvore de Confiabilidade (Avizienis, 2001).

IV. TOLERNCIA A FALHAS E A ENGENHARIA DE SOFTWARE

Figura 4 Pesquisas na rea de Engenharia de Software Relacionadas com Tolerncia a Falhas.

Figura 5 Tpicos de Pesquisas do SBES e ICSE Relacionados com Tolerncia a Falhas.

V.I - Engenharia de Requisitos

V.II - Manuteno e Reengenharia

V.III - Verificao e Validao

V.IV - Teste e Depurao

Figura 6 Diversidade de Aplicaes da Tcnica de Teste de Software (Durelli et al, 2011).

V.V - Arquitetura e Design

VI. TRATAMENTO DE EXCEES

VI.I - Anlise, Manuteno e Teste de Software

VI.II - Arquitetura, Design e Especificao de Software

VI.III Estudos Empricos

VII. TRATAMENTO DE EXCEES USANDO LINGUAGENS DE PROGRAMAO

VIII. O TRATAMENTO DE EXCEO NO DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS (2009-2012)

VIII.I - Anlise e Teste de Software

Listagem 1 Captura de uma Exceo atravs de um Aspecto (Figueroa e Tanter, 2011).

VIII.II - Arquitetura, Especificao e Design de Software

Anda mungkin juga menyukai