C ONSIDERAÇÕES FINAIS

A notação UML-AFR representa os pontos de extensão de um FOA sob o ponto de vista estático de um diagrama de classes/aspectos. Essa representação permite a rápida visualização, identificação e entendimento desses pontos de extensão presentes. Um ponto importante dessa notação é o uso de mecanismos de extensão leve da UML, permitindo a sua utilização com a abordagem de modelagem orientada a aspectos que mais convier ao desenvolvedor do framework, desde que esta abordagem seja baseada em UML e suporte construções para aspectos e conjuntos de junção.

Como exemplo do funcionamento da UML-AFR, a Figura 18 ilustra a modelagem do framework de segurança utilizando a UML-AFR em conjunto com a AODM. Nesse exemplo é possível notar como os estereótipos da UML-AFR identificam os pontos de extensão do framework em questão, mostrando que tanto o aspecto AccessControlWeb quanto o AccessControlLocal podem ser estendidos durante o reúso, e que nestes subaspectos deverá ser concretizado o conjunto de junção SecurityPoint, como indicado. O valor identificado presence também indica que a presença dos aspectos é opcional na aplicação final, pois a escolha de qual aspecto será estendido (ou até mesmo se nenhum, em caso de não haver a necessidade de segurança) depende dos requisitos da aplicação (se a aplicação é web ou é local).

Figura 18 – Framework de segurança modelado com UML-AFR e AODM. Fonte: O autor. <<aspect_extension>> AccessControlLocal <<pointcut>> FullSecurityPoint() + analyseRights() + denyAccess() <<aspect_extension>> AccessControlWeb <<pointcut>> FullSecurityPoint()

<<advice>> ad01 around(){base=FullSecurityPoint()} + analyseRights() + denyAccess() #myRequest #myResponse <<pointcut>> FullSecurityPoint() <<pointcut_extension>> SecurityPoint() <<aspect>> AccessControl {presence=optional} {presence=optional} hotspots

Entretanto, essa representação não está completa. A parte de declarações intertipo (introduções) foi deixada de fora nesta versão da notação por não haver um mecanismo de extensão genérico bem definido, tanto nas linguagens de POA quanto nas de modelagem, de para as mesmas; isso é deixado para uma nova versão da notação, quando tais mecanismos estiverem disponíveis. Além disso, alguns itens foram propositadamente omitidos para não prejudicar a legibilidade do modelo, como os valores envolvidos em uma seleção ou a identificação do padrão de projeto utilizado.

Outro ponto omitido na notação UML-AFR é a seqüência em que as atividades de reúso devem ocorrer. Especificar essa seqüência em um diagrama seria como programar um sistema inteiro de forma visual em diagramas de seqüência ou colaboração. Essa idéia possui um problema relativo à capacidade de tais diagramas conseguirem representar completamente as atividades de reúso, já que estes não são computacionalmente completos.

4 E

A

R

Além da documentação do projeto (estrutura, comportamento e arquitetura) e da identificação dos pontos de extensão, é necessário compreender como estes pontos devem ser preenchidos para que o framework seja corretamente reutilizado (instanciado e/ou composto com algum código), gerando assim a aplicação final. O preenchimento dos pontos de extensão é realizado por tarefas repetitivas como concretização de mecanismos de composição abstratos, adaptação de interfaces, redefinição de métodos, atribuição de valores e verificação de restrições. Como se trata de tarefas repetitivas, o uso de uma abordagem sistemática ajudaria a reduzir a quantidade de erros inerentes ao processo de reúso, acarretando em um projeto mais confiável da aplicação final.

Além disso, esse preenchimento deve seguir uma ordem pré-estabelecida pelo desenvolvedor do framework, uma vez que certos pontos de extensão podem depender de outros, além da possível dependência que pode existir entre as etapas do reúso (instanciação e composição). Por possuir total conhecimento do framework e de seu funcionamento, o desenvolvedor do framework deve ser capaz de transmitir este conhecimento, pela especificação da seqüência de atividades, parâmetros pertinentes e restrições necessárias, ao reutilizador (desenvolvedor da aplicação), de forma a auxiliá-lo a obter corretamente o projeto da aplicação final.

Se uma linguagem de programação capturasse todas essas atividades de reúso em instruções bem definidas, essa seqüência de atividades poderia ser determinada por um ou mais programas8 de reúso. O uso de uma linguagem de programação evita ambigüidades e falhas de entendimento em comparação com a linguagem natural, que possui uma natureza ambígua e interpretativa: dois reutilizadores podem interpretar distintamente a mesma especificação em linguagem natural. Além disso, abre espaço para que esses programas de reúso possam ser executados por um computador, permitindo auxílio automatizado.

Este trabalho define uma linguagem de programação, denominada RDL+Aspects, que captura as possíveis atividades envolvidas no processo de reúso de FOAs em declarações bem definidas e independentes do domínio do framework. Seus comandos manipulam elementos no nível de projeto, realizando, em conjunto com a interação do reutilizador, a transformação do projeto do framework no projeto da aplicação. A realização do reúso na fase de projeto, além de manter os programas de reúso independentes da linguagem de programação do

framework, permite uma melhor especificação da aplicação final antes da implementação, aumentando a correspondência entre projeto e implementação. Caso o reúso fosse feito somente na fase de implementação o projeto da aplicação final teria que ser refeito de modo a replicar as modificações causadas pelo reúso. Essa etapa adicional de engenharia reversa possivelmente aumentaria a taxa de erros gerados no processo de desenvolvimento da aplicação.