Вы находитесь на странице: 1из 5

Verificao Automtica de Situaes Excepcionais Atravs de Casos de Testes Aspectuais Baseados em Modelos

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: Atravs do paradigma de Programao Orientada a Aspectos (POA)


possvel alcanar a modularizao e o reuso de cdigo para tratar os interesses transversais dos sistemas, onde diversos estudos ensejam uma integrao dos mecanismos de tratamento de exceo com esse objetivo. Entretanto, estudos recentes destacam que ao promover essa integrao, o paradigma pode aumentar a propenso a defeitos nos sistemas, porque (i) a construo do cdigo para o tratamento de exceo pode ser feita de forma no intencional pelos aspectos, (ii) a falta de consistncia entre os aspectos e os componentes pode resultar em implementaes incorretas, alm de (iii) existirem evidncias que as excees no so capturadas quando os aspectos atuam como manipuladores de excees. Este trabalho prope uma plataforma de gerao automtica de casos de testes que implementaro inspetores de defeitos orientados a aspectos, cuja integrao entre os aspectos e componentes ser feita no nvel de metamodelos, o que resultar em uma maior consistncia na criao dos aspectos com o objetivo de contornar essas barreiras.

I. INTRODUO
A necessidade de melhoria na qualidade do 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 (Florio, 2008). Assim, a nica alternativa eficiente seria alcanar a confiabilidade incorporando os mecanismos de tolerncia a falhas na camada de software (Randell, 1975). Vrias tcnicas, especialmente o tratamento de exceo, foram incorporadas s necessidades de confiabilidade e deteco de falhas na Engenharia de Software. O tratamento de excees foi apresentado na dcada de 90, onde (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) tenta promover uma integrao dos mecanismos de tratamento de exceo, combinados com a tecnologia de POA e os estudos despertaram vrias questes: embora o paradigma possa ser utilizado para promover a modularidade e a reutilizao do cdigo de tratamento de exceo (Lippert e Lopes, 2000), possvel observar em diversos estudos que tambm pode aumentar a propenso a defeitos nos sistemas (Ferrari et al, 2010). Isso se deve ao fato que: (i) a construo do cdigo para o tratamento de exceo pode ser feita de forma no intencional, quando as excees so lanadas e capturadas de forma inesperada por existir algum tratamento no cdigo de um aspecto. (ii) a falta de consistncia entre os aspectos e componentes, pode resultar em implementaes incorretas e (iii) existem evidncias que as excees no so capturadas quando os aspectos atuam como manipuladores de excees. Por conta desses problemas, este trabalho apresenta uma plataforma de gerao automtica de casos de testes que implementaro inspetores de defeitos orientados a

aspectos. Na seo II so apresentados os problemas enfrentados com a adoo da POA para o tratamento de situaes excepcionais e na seo III uma breve apresentao da plataforma proposta neste trabalho. Por fim, as concluses e referncias utilizadas neste estudo.

II. O TRATAMENTO DE EXCEO NO DESENVOLVIMENTO DE SOFTWARE


ORIENTADO A ASPECTOS

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. Tambm, encapsulando essas situaes em tratadores e definindo quais partes dos mdulos devero ter regies protegidas, estas regies podem estar associadas de forma explcita nas interfaces dos mdulos (Bernado et al, 2011). A integrao dos mecanismos de tratamento de exceo visa a modularizao e reutilizao de cdigo dessas situaes excepcionais e combinados com o paradigma de Programao Orientado a Aspectos (POA) trouxeram tona diversas questes (Coelho et al, 2009). Embora a POA tenha sido defendida por um grupo de pesquisadores como um meio para promoo da modularidade e reutilizao de cdigo de tratamento de exceo (Lippert e Lopes, 2000) o uso do paradigma pode aumentar a propenso a erros nos sistemas. 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 se 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 ser lanada uma exceo do tipo FileNotFoundException, que interceptada pelo manipulador implementado em AspectJ. 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 (Coelho et al, 2011). possvel observar em diversos estudos que o uso dos tratadores pode aumentar a propenso a erros nos sistemas, inclusive h evidncias que as excees podem no ser capturadas quando os aspectos atuam como manipuladores, resultando em falhas imprevisveis no sistema (Coelho et al, 2011). Outro problema a falta de consistncia entre aspectos e componentes por causa da transparncia. A transparncia (obliviousness) o ato ou o efeito de deixar algo transparente, no sentido de poder ser esquecido ou passar despercebido. Nesse contexto, a propriedade de transparncia dos aspectos permite que os componentes no necessitem ser preparados para receber qualquer melhoria proporcionada por eles (Chavez, 2004). Assim, o uso dessa propriedade tem sido controversa, pois alguns estudos contradizem a intuio comum que a utilizao dos pontos de juno a principal fonte de defeitos, pois outros mecanismos, atualmente disponveis em AspectJ (e.g. pontos de juno, adendos e declaraes inter-tipo) tambm so propensos a falhas (Ferrari et al, 2010).

III. VERIFICAO AUTOMTICA DE EXCEES


Diante das barreiras apresentadas na seo anterior, este estudo prope uma plataforma para derivar casos de testes de situaes excepcionais que implementaro inspetores de defeitos orientados a aspectos. A plataforma ser construda seguindo o processo de verificao automtica exibido na Figura 1.

Figura 1 Processo de Verificao Automtica baseado em Silva e Barreto 2008.

Os casos de testes sero baseados em modelos, aps a criao (2) e verificao do domnio da aplicao (3) com base na especificao dos requisitos (1). Esses passos elevam a confiabilidade no entendimento do prposito da aplicao e reduz a quantidade de casos de testes desnecessrios e ambguos. Atravs de um reasoning, ser possvel verificar semanticamente as propriedades das classes do domnio que sero afetadas pelos aspectos, alm de definir uma dicotomia aspecto-base entre os aspectos e componentes que representaro as classes de falhas do domnio. Atravs da criao do Modelo Independente de Plataforma (PIM) (4) ser possvel estabelecer uma ponte entre os metamodelos de: aspectos, classes de falhas e domnio da aplicao (5), proporcionando na composio destes modelos uma relao consistente entre os aspectos, componentes e mecanismos de tratamento de exceo. Com base nos

metamodelos ser possvel realizar a gerao de Modelos Especficos de Plataforma (PSM) (7) que contemplaro os modelos funcionais de uma plataforma: cdigo de aplicao (e.g. Java) e casos de testes (6).

Figura 2 - Construo e Composio de Modelos Especficos de Plataforma.

O modelo funcional composto pelas classes de domnio ser afetado pelo conjunto de casos de testes que implementaro os aspectos, onde os casos de teste sero construdos conforme critrios de testes funcionais a serem definidos na criao do modelo PSM (e.g. regra de transformao de modelos ou perfil arquitetural) para sua gerao automtica (8). Por ltimo, com o advento do processo de weaving da POA, atravs da combinao dos modelos PSM (e.g. modelo de aplicao e casos de testes) ser possvel executar os testes funcionais implementados nos pontos de juno dos aspectos, afim de verificar a assertividade do cdigo em relao a especificao (Figura 2 Passo 4).

IV. CONCLUSO
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). Nos ltimos anos, a integrao desses mecanismos combinados com a Programao Orientada a Aspectos (POA) despertaram o interesse da comunidade acadmica e levantaram diversas questes. Embora a POA seja utilizada 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. O estudo sugere uma plataforma que permitir a gerao de casos de testes baseados em modelos, onde a implementao seguir o paradigma de POA e os casos de testes sero gerados considerando os modelos de classes de falhas e de domnio de aplicao atravs dos seus respectivos metamodelos. Com isso a plataforma ir: (i) evitar os enganos cometidos pela codificao manual, (ii) incluir o tratamento de exceo em fases

anteriores ao desenvolvimento de software, (iii) evitar o tratamento de exceo de forma no intencional, (iv) garantir a consistncia entre os aspectos e componentes e (v) aumentar a evidncia de que as excees podem ser capturadas pelos aspectos. O prximo passo do estudo ser a construo da plataforma com todos os seus componentes e a realizao de um experimento para conhecer os seus benefcios e limitaes.

REFERNCIAS
[1] 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. [2] 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. [3] 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). [4] 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. [5] 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. [6] 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. [7] Florio, V., Blondia, C.. (2008) A Survey of Linguistic Structures for ApplicationLevel Fault Tolerance, ACM Computing Surveys, Vol. 40, N2, Article 6, Abril. [8] 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. [9] 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. [10] Randell, B.. (1975) "System Structure for Software Fault Tolerance". IEEE Transactions on Software Engineering. IEEE Press SE-1, 1975. [11] 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. [12] 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.

Вам также может понравиться