Regras de Design

Antes de iniciar a criação das regras de design foi feito um estudo juntamente com os arquitetos de software. Foram encontradas duas famílias de exceções definidas para o SIGs. Uma família de exceções checadas que herdam da classe java.lang.Exception, sendo a mais importante a UFRNException, que é a raiz da hierarquia de exceções checadas da arquitetura como mostrado nas Figuras 14 e 15.

Figura 14: Hierarquia de exceções (primeiro nível).

Figura 15: Hierarquia de exceções filhas de UFRNException.

A seguir segue uma breve explicação para que serve cada um dos tipos de exceções filhas de UFRNException.

i. br.ufrn.arq.erros.ArqException: Exceções lançadas por elementos da arquite- tura.

ii. LimiteResultadosException estende DAOException: Exceção disparada quando uma consulta retorna um número maior de resultados que o permitido, exigindo que o usuário restrinja os termos de busca.

iii. br.ufrn.arq.erros.SegurancaException: Exceção disparada para falhas de segu- rança.

iv. br.ufrn.arq.erros.HostNaoAutorizadoException: Exceção utilizada para infor- mar violação de acesso para hosts não autorizados.

v. br.ufrn.arq.erros.NegocioException: Esta exceção é emitida sempre que o erro em questão for um erro de regra de negócio.

Além deste conjunto de exceções checadas, temos ainda um conjunto de exceções não checadas, ilustradas na Figura 16.

Figura 16: Hierarquia de exceções Runtime.

A seguir segue uma breve descrição de cada uma das exceções Runtime definidas para os sistemas SIGs.

i. br.ufrn.arq.erros.RuntimeNegocioException: Está exceção é emitida sempre que o erro em questão for um erro de regra de negócio. Igual a NegocioException, mas do tipo unchecked.

ii. br.ufrn.arq.web.conversation.ConversationNotActiveException: Exceção dis- parada quando o usuário tenta acessar um método de um managed bean com escopo conversation e a conversação ainda não foi iniciada ou já foi finalizada.

iii. br.ufrn.arq.negocio.validacao.ValidationException: Exceção disparada in- formando que um tipo de dado não é suportado pela validação através de anotações.

iv. br.ufrn.arq.erros.TokenNaoValidadoException: Exceção disparada quando um token de autenticação, por exemplo de WebServices, é inválido.

v. ConfiguracaoAmbienteException estende de RuntimeException: Esta exceção é sempre emitida quando existe erro de configuração de ambiente.

Nos sistemas SIGs quando uma exceção não é tratada pela aplicação e chega à camada de controle, ela é capturada pela classe ViewFilter que gerencia todas as requisições e respostas HTTP, ou seja toda a comunicação com os clientes passam por essa classe. Se uma exceção chegar até ela, ela invoca o método handleException da classe ExceptionHandler. A classe ExceptionHandler é responsável por realizar o tratamento das exceções não tratadas por componentes da camada de negócio ou dados. O método handlerException captura da sessão informações relativas ao usuário logado no momento em que ocorreu a exceção, e utiliza algumas heurísticas para identificar que tipo de exceção ocorreu e assim tratar. Neste momento o método handleException invoca o método da classe ExceptionChain que será responsável pelo tratamento propriamente dito de cada tipo de exceção. O tratamento consiste em, a partir do tipo de exceção que foi lançada, apresentar ao usuário uma mensagem de erro correspondente. A Figura 17 mostra o diagrama de sequência de operações que são realizadas quando uma exceção chega até a classe ViewFilter.

Figura 17: Interação entre as classes envolvidas no tratamento de exceções quando a aplicação não trata e chega até a classe ViewFilter.

Após levantar e documentar o fluxo excepcional em conjunto com os arquitetos de software foram então definidas as principais regras referentes ao fluxo excepcional.

i. A exceção ArqException é uma exceção referente a erros na arquitetura e sempre deve ser tratada pela classe br.ufrn.arq.web.ViewFilter.

ii. A exceção UFRNException é a exceção pai de todas as outras exceções, é uma exceção genérica devendo ser evitada ser instanciada ou tratada no código dos sistemas SIGRH e SIGAA, quem deve realizar o tratamento dessa exceção é a classe br.ufrn.arq.web.ViewFilter.

iii. A exceção NegocioException é uma exceção que se refere a um erro/aviso referente ao negócio da aplicação e deve ser tratada pela classe br.ufrn.arq.web.ViewFilter. Essa regra é importante para que o desenvolvedor não silencie exceções de negócio ou dispare outra exceção que distorça a real mensagem que deveria ser exibida ao usuário.

iv. A exceção DAOException deve ser tratada pela classe br.ufrn.arq.web.ViewFilter.

v. A exceção SegurancaException deve ser tratada pela classe br.ufrn.arq.web.ViewFilter.

As regras criadas usando a linguagem ECL estão na Tabela 3, já na Figura 18 é possível ver todas as regras também só que sintetizadas em apenas uma construção da ECL.

Tabela 3: Regras criadas para os sistemas SIGRH e SIGAA utilizando a linguagem ECL. ID ECL Regra 1 ehrule { type = p a r t i a l s i g n a l e r = * exceptionAndHandlers = { exception = b r . u f r n . a r q . e r r o s . A r q E x c e p t i o n handler = [ b r . u f r n . a r q . web . V i e w F i l t e r . * ] } } ; 2 ehrule { type = p a r t i a l s i g n a l e r = * exceptionAndHandlers = { exception = b r . u f r n . a r q . e r r o s . UFRNException handler = [ b r . u f r n . a r q . web . V i e w F i l t e r . * ] } } ; 3 ehrule { type = p a r t i a l s i g n a l e r = * exceptionAndHandlers = { exception = b r . u f r n . a r q . e r r o s . N e g o c i o E x c e p t i o n handler = [ b r . u f r n . a r q . web . V i e w F i l t e r . * ] } } ; 4 ehrule { type = p a r t i a l s i g n a l e r = * exceptionAndHandlers = { exception = b r . u f r n . a r q . e r r o s . DAOException handler = [ b r . u f r n . a r q . web . V i e w F i l t e r . * ] } } ;

Tabela 3: Regras criadas para os sistemas SIGRH e SIGAA utilizando a linguagem ECL. ID ECL Regra 5 ehrule { type = p a r t i a l s i g n a l e r = * exceptionAndHandlers = { exception = b r . u f r n . a r q . e r r o s . S e g u r a n c a E x c e p t i o n handler = [ b r . u f r n . a r q . web . V i e w F i l t e r . * ] } } ; 1 ehrule { 2 type = p a r t i a l 3 s i g n a l e r = * 4 exceptionAndHandlers = {

5 exception = br . u f r n . a r q . e r r o s . ArqException handler =

[ br . u f r n . a r q . web . V i e w F i l t e r . * ]

6 exception = br . u f r n . a r q . e r r o s . UFRNException handler =

[ br . u f r n . a r q . web . V i e w F i l t e r . * ]

7 exception = br . u f r n . a r q . e r r o s . N e g o c i o E x c e p t i o n handler =

[ br . u f r n . a r q . web . V i e w F i l t e r . * ]

8 exception = br . u f r n . a r q . e r r o s . DAOException handler =

[ br . u f r n . a r q . web . V i e w F i l t e r . * ]

9 exception = br . u f r n . a r q . e r r o s . S e g u r a n c a E x c e p t i o n handler =

[ br . u f r n . a r q . web . V i e w F i l t e r . * ]

10 }

11 } ;

Figura 18: Regras para os sistemas SIGRH e SIGAA, sintetizadas em uma única construção da ECL.

Como pode ser observado nas regras definidas existe uma centralização de que as exceções devem ser tratadas na classe ViewFilter. Isso é uma característica da arquitetura dos sistemas SIGs que prever que a maior parte das exceções devem ser tratadas pela arquitetura do sistema, eximindo assim o desenvolvedor da responsabilidade de tratar diversas exceções.

4.1.5

Resultados

A ferramenta DAEH foi utilizada para detectar violações das regras de design propostas para os sistemas SIGRH e SIGAA. A Tabela 4 apresenta o log de violação de uma regra de design enviada ao servidor. Todas as violações das regras de design do fluxo excepcional

são enviadas para um servidor localizado na nuvem.

Tabela 4: Texto enviado para o servidor DAEH devido a uma quebra de regra de design.

<Exception:class br.ufrn.arq.erros.NegocioException> expected: <Handlers:[br.ufrn.arq.web.ViewFilter.*]> but was <Handler:UsuarioMBean.logar()>

Execução da DAEH durante testes de aceitação manuais

Num período de 5 dias a versão 4.17.4 do SIGRH foi monitorada e foi exercitada por testes manuais. Tiveram nesse período 12027 violações de regras de design da ECL. Nota-se na Tabela 5 que apenas três regras de design foram violadas (isto é, as regras 1,3 e 4). Para a regra número 3 ocorreu um grande número de violações, analisando as violações associadas com a regra de design 3, observou-se que as violações foram causadas por 8 manipuladores diferentes. O número de violações foi tão alto para a regra 3, pois o mesmo trecho de código foi exercitado mais de uma vez durante os testes de aceitação.

Tabela 5: Número de violações de regras nos testes manuais.

ID ECL SIGRH 4.17.4 Violações em locais diferentes

1 6 3

2 0 0

3 12 015 17

4 6 4

5 0 0

Execução da DAEH durante testes de aceitação automatizados

As regras definidas para a versão 4.17.4 também foram verificadas em uma versão posterior do SIGRH (versão 4.21.0). Para verificar o cumprimento das regras desenvolvemos

um conjunto de testes de aceitação automatizados utilizando Selenium e WebDriver e colocamos a DAEH para monitorar o sistema enquanto os testes de aceitação automatizados eram executados. No geral 65 testes foram executados em 55 minutos e 6 violações de contrato foram detectadas, como pode ser visto na Tabela 5.

Nós também colocamos a DAEH para verificar as regras de design referentes ao tratamentos de exceções do SIGAA. O SIGAA também não tinha qualquer documentação referente à política de tratamento de exceções, assim conversamos com o arquiteto e aplicamos o mesmo conjunto de 5 regras de design que foram definidos para os SIGs e que estão na Tabela 3. A bateria de testes automatizados contendo 65 testes foram executados em 83 minutos e 3 violações foram detectadas. A Tabela 6 resume as violações detectadas. A Tabela 7 mostra os tempos gastos na execução das baterias de testes automatizados.

Tabela 6: Violações encontradas durante execução dos testes automatizados.

ID ECL SIGRH 4.21.0 SIGAA 3.8.0

1 2 2

2 0 0

3 4 1

4 0 0

5 0 2

Tabela 7: Tempos de execução dos testes automatizados.

Metricas SIGRH 4.21.0 SIGAA 3.8.0

Testes Automatizados 65 69

Tempo Gasto 55 min 84 min

4.1.6

SIGAA Mobile

Em paralelo e complementar a este trabalho foi desenvolvido em um trabalho de conclusão de curso uma versão da DAEH para aplicações móveis na plataforma Android (MEDEIROS, 2015). Essa versão da DAEH chamada de Rasthro não realiza a verificação das regras no próprio aplicativo por questões de desempenho, apenas intercepta todo o tratamento de exceções e envia ao servidor remoto da DAEH. A Figura 19 mostra uma visão geral de como ocorrem às interações entre a Rasthro e o servidor remoto da DAEH.

Figura 19: Esquema geral de interação entre a Rasthro e os módulos do servidor DAEH.

O monitoramento ocorre no cliente Android, que consiste em um aplicativo equipado com a biblioteca de monitoramento. Este aplicativo, através da biblioteca, faz requisições para o servidor web, enviando as informações recolhidas até então (MEDEIROS, 2015). As requisições que são feitas seguem as especificações REST (Representational State Transfer ), um estilo arquitetural que, no campo dos serviços web, determina uma série de padrões, restrições e regras para referência a objetos e serviços (FIELDING, 2000).

O módulo Minerador (Serviço WEB) consiste no servidor e é responsável por manter e dar acesso à base de dados. Seu submódulo chamado Minerador-WEB é encarregado de receber as requisições dos clientes, aplicar as devidas regras de negócio e se comunicar com o submódulo Minerador-Domínio, que faz a gerência da base de dados.

Para avaliar essa nova vertente foi realizado um estudo de caso com o SIGAA Mobile versão Beta, aplicação utilizada por docentes e discentes da UFRN, as métricas do SIGAA Mobile estão na Tabela 8.

Tabela 8: Características do projeto SIGAA Mobile.

SIGAA Mobile Linhas de código 13868 Núm. de classes 107 Núm. de blocos try 73 Núm. de blocos catch 96 Núm. de blocos finally 5

No SIGAA Mobile durante o período de monitoramento foram interceptadas 58 exceções e enviadas ao servidor da DAEH. Na Tabela 9 são mostradas as exceções e a quantidade interceptadas. Vale ressaltar que para as aplicações Android ainda não está sendo realizada a verificação de regras do fluxo excepcional, visto que essa verificação nesses casos passará a ser realizada no servidor da DAEH para não consumir recursos do dispositivo móvel. Essa melhoria está inclusa no conjunto de melhorias a serem desenvolvidas em trabalhos futuros.

Tabela 9: Relação das exceções identificadas no aplicativo SIGAA Mobile.

Exceção (SIGAA Mobile) Quantidade de Interceptações java.lang.reflect.InvocationTargetException 9

java.lang.NullPointerException 4

java.lang.IllegalStateException 1

4.1.7

Análise dos resultados

Avalidando-se as questões postas na Subseção 4.1.1 de acordo com os dados coletados chega-se a seguinte conclusão acerca de cada uma das questões de pesquisa.

i. A linguagem ECL permitiu definir todas as regras referentes ao tratamento de exceção? Como mostrado na Subseção 4.1.4 todas as regras de design existentes para os SIGs referentes ao tratamento de exceção foram criadas utilizando a ECL. Vale salientar que apesar de todas as regras terem sido cridas elas não são tão complexas.

ii. Os arquitetos de software entenderam a linguagem e a ferramenta e necessidade da abordagem para o desenvolvimento de software? Sim, tantos os arquitetos e desenvolvedores entenderam o conceito da linguagem e da ferramenta, tanto que participaram da definição e criação das regras bem como da análise das violações encontradas.

iii. Com a ferramenta foi possível identificar violações de regras de design referente ao tratamento de exceção? Sim, como mostra a Subseção 4.1.5 onde foram identificados um número razoável de violações.

De acordo com os dados coletados sejam eles quantitativos ou qualitativos podemos concluir que as questões foram atendidas quase que em sua totalidade e assim a meta

foi alcançada que foi constatar que a ferramenta desenvolvida possui os atributos de usabilidade e eficiência necessários a sua aplicação ao monitoramento de regras referentes ao tratamento de exceção.

4.2

Estudo de Caso para o framework JUnit

O JUnit é um framework open-source para escrever testes de unidade, criado por Erich Gamma e Kent Beck. Ele foi escolhido como estudo de caso devido a possuir uma extensa bateria de testes de unidade, além de possuir uma boa organização do fluxo de tratamento de exceções o que facilita a criação de regras de design de tratamento de exceções. O intuito do uso do JUnit como estudo de caso é duplo, verificar se a ferramenta pode ser utilizada em conjunto com testes unitários e de integração, como também identificar mudanças na política de tratamento de exceções entre versões diferentes da aplicação.

4.2.1

Objetivo

O objetivo desse estudo de caso é avaliar se a ferramenta DAEH e a linguagem ECL pode ser utilizada em conjunto com a suíte de testes unitários e de integração do JUnit para verificar as regras referentes ao tratamento de exceção.

Algumas questões foram traçadas com o intuito de avaliar o objetivo, as questões definidas são:

i. A linguagem ECL permitiu definir todas as regras referentes ao tratamento de exceção?

ii. Com a ferramenta foi possível identificar violações de regras de design referente ao tratamento de exceção?

4.2.2

Metodologia

O JUnit não possui documentadas as regras de design referentes ao tratamento de exceções, então foi analisado o código fonte da aplicação, versão 4.6, e criada uma série de regras de design.

No intuito de avaliar a abordagem/ferramenta proposta, os seguintes procedimentos foram realizados no JUnit:

i. Análise da versão 4.6 do JUnit e criação das regras de design do tratamento de exceções usando a linguagem ECL.

ii. A ferramenta DAEH foi aplicada ao JUnit na versão 4.6 e para exercitá-lo foi utilizada a suíte de testes unitários do próprio JUnit.

iii. A ferramenta DAEH foi aplicada ao JUnit para as versões 4.7, 4.8 e 4.9 e para exercitá-lo foi utilizada a suíte de testes unitários do próprio JUnit.

4.2.3

Regras de Design

Foi realizado um estudo do código e da suíte de testes do JUnit da versão 4.6 e levantada às regras para o tratamento das exceções de forma a não ocorrer nenhuma quebra de regra para essa versão. O intuito disso é verificar se ocorrem alterações no fluxo de tratamento de exceções em versões posteriores do framework. Foram criadas oito regras de design como pode ser observado na Tabela 10.

Tabela 10: Regras de design para o framework JUnit.

Regra

ehrule {

type = p a r t i a l

s i g n a l e r = o r g . j u n i t . e x p e r i m e n t a l . max . MaxHistory . r e a d H i s t o r y ( . . ) exceptionAndHandlers = {

exception = o r g . j u n i t . e x p e r i m e n t a l . max . CouldNotReadCoreException handler = [ o r g . j u n i t . e x p e r i m e n t a l . max . MaxHistory . f o r F o l d e r ( . . ) ] }

} ; ehrule { type = p a r t i a l s i g n a l e r = o r g . j u n i t . i n t e r n a l . b u i l d e r s . A n n o t a t e d B u i l d e r . * exceptionAndHandlers = { exception = o r g . j u n i t . r u n n e r s . model . I n i t i a l i z a t i o n E r r o r

handler = [ o r g . j u n i t . r u n n e r . R e q u e s t . * o r g . j u n i t . e x p e r i m e n t a l . max . MaxCore . * o r g . j u n i t . r u n n e r s . S u i t e . * ] }

Tabela 10: Regras de design para o framework JUnit. Regra ehrule { type = p a r t i a l s i g n a l e r = o r g . j u n i t . r u n n e r s . ParentRunner . * exceptionAndHandlers = { exception = o r g . j u n i t . r u n n e r s . model . I n i t i a l i z a t i o n E r r o r

handler = [ o r g . j u n i t . r u n n e r . R e q u e s t . * o r g . j u n i t . e x p e r i m e n t a l . max . MaxCore . * o r g . j u n i t . r u n n e r s . S u i t e . * ] } } ; ehrule { type = p a r t i a l s i g n a l e r = o r g . j u n i t . r u n n e r s . S u i t e . * exceptionAndHandlers = { exception = o r g . j u n i t . r u n n e r s . model . I n i t i a l i z a t i o n E r r o r

handler = [ o r g . j u n i t . r u n n e r . R e q u e s t . * o r g . j u n i t . e x p e r i m e n t a l . max . MaxCore . * o r g . j u n i t . r u n n e r s . S u i t e . * ] } } ; ehrule { type = p a r t i a l s i g n a l e r = o r g . j u n i t . r u n n e r s . model . R u n n e r B u i l d e r . * exceptionAndHandlers = { exception = o r g . j u n i t . r u n n e r s . model . I n i t i a l i z a t i o n E r r o r

handler = [ o r g . j u n i t . r u n n e r . R e q u e s t . * o r g . j u n i t . e x p e r i m e n t a l . max . MaxCore . * o r g . j u n i t . r u n n e r s . S u i t e . * ] } } ; ehrule { type = p a r t i a l s i g n a l e r = o r g . j u n i t . i n t e r n a l . r u n n e r s . J U n i t 4 C l a s s R u n n e r . * exceptionAndHandlers = { exception = o r g . j u n i t . r u n n e r . m a n i p u l a t i o n . NoTestsRemainException handler = [ o r g . j u n i t . i n t e r n a l . r e q u e s t s . F i l t e r R e q u e s t . * o r g . j u n i t . r u n n e r s . ParentRunner . * ] } } ;

Tabela 10: Regras de design para o framework JUnit. Regra ehrule { type = p a r t i a l s i g n a l e r = o r g . j u n i t . r u n n e r s . ParentRunner . * exceptionAndHandlers = { exception = o r g . j u n i t . r u n n e r . m a n i p u l a t i o n . NoTestsRemainException handler = [ o r g . j u n i t . i n t e r n a l . r e q u e s t s . F i l t e r R e q u e s t . * o r g . j u n i t . r u n n e r s . ParentRunner . * ] } } ; ehrule { type = p a r t i a l s i g n a l e r = * exceptionAndHandlers = { exception = j u n i t . framework . A s s e r t i o n F a i l e d E r r o r handler = [ j u n i t . framework . T e s t R e s u l t . * j u n i t . t e s t s . * ] } } ;

4.2.4

Resultados

A ferramenta DAEH foi utilizada para detectar violações as regras de design em quatro versões do JUnit (4.6, 4.7, 4.8 e 4.9) a fim de verificar se ocorreu alteração no fluxo excepcional em versões posteriores a versão 4.6, já que o conjunto de regras criadas foi com base no código fonte da versão 4.6. Com isso podemos verificar se as regras de tratamento de exceções foram alteradas em versões posteriores.

Na Tabela 11 é mostrada a quantidade de violações para cada versão, nenhuma regra foi violada, o que indica que o fluxo de tratamento de exceções não sofreu mudanças a ponto de alterar as regras de tratamento de exceções. Esse resultado já era esperado já que o JUnit é um framework bem projetado e possui uma boa organização do código fonte.

Tabela 11: Violações das regras de design do framework JUnit.

Versão Número de Violações

4.6 0

4.7 0

4.8 0

4.9 0

Apesar do estudo de caso com o JUnit não ter encontrado erros, o consideramos importante para mostrar a viabilidade da ferramenta em ser utilizada em conjunto com testes unitários e de integração para avaliar os fluxos excepcionais. Também é importante para mostrar a utilidade da ferramenta em garantir que as regras de design não serão degradadas ao gerar uma nova versão.

4.2.5

Análise dos resultados

Avalidando-se as questões postas na Subseção 4.2.1 de acordo com os dados coletados chega-se a seguinte conclusão acerca de cada uma das questões de pesquisa.

i. A linguagem ECL permitiu definir todas as regras referentes ao tratamento de exceção? Como não foi encontrada uma documentação que definisse as regras do tratamento de exceções para o JUnit, foi criada uma base de regras baseada no código fonte e para esse conjunto de regras mostrado na Subseção 4.2.3 foi possível escrever todas as regras usando a ECL.

ii. Com a ferramenta foi possível identificar violações de regras de design referente ao tratamento de exceção? Não, como mostra a Subseção 4.2.4 não foi identificada nenhuma violação a regras do tratamento de exceções.

De acordo com os dados coletados sejam eles quantitativos ou qualitativos podemos concluir que a primeira questão de pesquisa foi atendida enquanto a segunda não, sendo assim o objetivo foi atingindo parcialmente.

No documento Especificação e monitoramento dinâmico da política de tratamento de exceções (páginas 47-62)