Para facilitar o processo de tradu¸c˜ao seguindo as regras estabelecidas na Se¸c˜ao 4.1 e evitar que erros sejam cometidos na aplica¸c˜ao destas regras, foi constru´ıda uma ferramenta que, a partir de uma especifica¸c˜ao v´alida em AspectualAcme, gera a design rule correspondente utilizando a linguagem de especifica¸c˜ao de design rules. A Figura 4.24 mostra os passos para o processo de tradu¸c˜ao. A partir de qualquer especifica¸c˜ao v´alida em AspectualAcme ´e poss´ıvel gerar uma especifica¸c˜ao na linguagem de design rules utilizando as regras de tradu¸c˜ao pr´e-definidas, apresentadas na Se¸c˜ao 4.1, e as regras definidas pelo usu´ario que podem ser inseridas no tradutor atrav´es do mecanismo de propriedades.
O tradutor ´e composto por cinco componentes principais exibidos na Figura 4.25. O componente AspectualAcme Model utiliza as bibliotecas providas pelo compilador Aspec-
4.2 O TRADUTOR 55
Figura 4.24 Funcionamento do Tradutor
tualAcme para verificar se a especifica¸c˜ao ´e v´alida e obter uma ´arvore sint´atica dessa especifica¸c˜ao que ser´a a entrada do processo de tradu¸c˜ao. O componente DR Model possui as classes necess´arias para gerar a ´arvore sint´atica do conjunto de design rules resultante do processo de tradu¸c˜ao. O componente PrettyPrinter DR possui as rotinas para imprimir a ´arvore sint´atica e o m´odulo de configura¸c˜ao da linguagem de design ru-
les. O componente Properties possui todas as propriedades que ir˜ao verificar ou gerar design rules mais espec´ıficas. Finalmente o componente Translator utiliza o compo-
nente AspectualAcme Model para obter a ´arvore sint´atica inicial e, a partir das regras de tradu¸c˜ao implementadas pelo compilador e aquelas provenientes da utiliza¸c˜ao de propri- edades implementadas no componente properties, produz a ´arvore sint´atica da linguagem de especifica¸c˜ao de design rules, descrita pelo componente DR Model que ser´a impressa pelas rotinas do componente Printer DR
Figura 4.25 Componentes do Tradutor
A ferramenta foi constru´ıda na linguagem Java e por n˜ao utilizar nenhum recurso externo dependente de plataforma, por exemplo, banco de dados, torna-se automatica- mente port´avel entre plataformas. A arquitetura da ferramenta foi escolhida objetivando maior flexibilidade na utiliza¸c˜ao de novas propriedades. Atrav´es do uso de propriedades ´e poss´ıvel verificar ou gerar novas design rules apenas adicionando uma classe ao tradu- tor. A Figura 4.26 exibe o diagrama de classes com os principais classes do componente
property. Atualmente quatro propriedades (provided, required, provides e requires) foram
implementadas no escopo das portas, embora outras propriedades possam ser inclu´ıdas para verificar ou gerar design rules mais espec´ıficas. Para adicionar uma nova proprie- dade, por exemplo, no escopo das portas, basta estender a classe PortProperty e colocar a classe no pacote destinado `as propriedades das portas. O tradutor utiliza o mecanismo de Reflection da linguagem Java e detecta automaticamente a existˆencia dessa nova pro- priedade. Apesar de utilizar caracter´ısticas, como o mecanismo de reflex˜ao da plataforma Java, que podem degradar um pouco a eficiˆencia, o processo de tradu¸c˜ao, em todas as arquiteturas avaliadas, produziu resultados praticamente instantˆaneos.
Figura 4.26 Funcionamento do Tradutor
Atualmente o tradutor possui uma interface simples onde a especifica¸c˜ao em Aspectu- alAcme ´e escrita ou ainda copiada e a especifica¸c˜ao da design rule ´e exibida. O objetivo inicial era integrar o tradutor, atrav´es da cria¸c˜ao de um plugin, ao ambiente AspectualAc- meStudio. Entretanto, esse ambiente para constru¸c˜ao de especifica¸c˜oes AspectualAcme ainda n˜ao foi completamente constru´ıdo nem disponibilizado a tempo de integrar-se ao tradutor desenvolvido.
CAP´ITULO 5
AVALIAC¸ ˜AO
Para avaliar as regras de tradu¸c˜ao entre a linguagem AspectualAcme e a linguagem de especifica¸c˜ao de design rules apresentadas no Cap´ıtulo 4, definimos dois cen´arios para executar a tradu¸c˜ao de algumas arquiteturas cl´assicas de sistemas apresentados na lite- ratura. No primeiro cen´ario ´e exibido um sistema onde os interesses transversais n˜ao s˜ao considerados. No segundo cen´arios esses interesses s˜ao considerados e descritos usando AspectualAcme. Para cada uma das design rules geradas definimos alguns crit´erios de avalia¸c˜ao dos resultado obtidos.
As tradu¸c˜oes apresentadas neste cap´ıtulo foram realizadas automaticamente pela fer- ramenta constru´ıda, evitando que design rules fossem esquecidas ou ainda mal interpre- tadas. Al´em disso a utiliza¸c˜ao da ferramenta de gera¸c˜ao diminui o tempo necess´ario para que o projetista definisse manualmente essas design rules.
5.1 CRIT´ERIOS DE AVALIAC¸ ˜AO
Os crit´erios de avalia¸c˜ao de qualidade utilizados foram os definidos pela Norma ISO/IEC 9126 [dNeT07] que divide-os em dois grupos. No primeiro grupo ´e a avaliada a funcionali- dade da solu¸c˜ao verificando se o resultados obtidos satisfazem as necessidades declaradas. Nesse sentido avaliamos a corretude dos resultados, verificando se todas as design rules descritas no modelo de arquitetura foram mapeadas para a linguagem de descri¸c˜ao de
design rules. A completude da solu¸c˜ao foi avaliada mostrando-se que ´e poss´ıvel gerar as design rules mesmo realizando mudan¸cas nas arquiteturas apresentadas. Quanto mais
detalhada a especifica¸c˜ao da arquitetura mais design rules ser˜ao obtidas. No segundo grupo ´e avaliado como a solu¸c˜ao foi implementada verificando a confiabilidade, usabili- dade, eficiˆencia, manutenibilidade e portabilidade do produto desenvolvido.
Seguindo esses crit´erios nas se¸c˜oes seguintes avaliamos alguns cen´arios de arquiteturas cl´assicas, verificando a funcionalidade da solu¸c˜ao avaliando e a sua corretude atrav´es de an´alises das design rules obtidas, mostrando vantagens e problemas que poderiam acontecer caso fossem esquecidas ou mal interpretadas. Nos cen´arios tamb´em detalhamos algumas dessas arquiteturas atrav´es da utiliza¸c˜ao de representa¸c˜oes, com o intuito de avaliar a completude, permitindo que design rules mais espec´ıficas fossem obtidas. Neste cap´ıtulo n˜ao avaliamos formalmente os crit´erios relativos `a implementa¸c˜ao da solu¸c˜ao, mas alguns deles, como eficiˆencia e portabilidade, s˜ao discutidos na Se¸c˜ao 4.2.