Aspectual Connectors, Base Roles, Crosscutting Roles e Attachments

Os aspectual connectors tˆem os mesmos objetivos dos connectors, por´em possuem novos

roles. O prop´osito desses novos roles ´e distinguir o papel dos elementos numa intera¸c˜ao crosscutting. A interface base role representa a interface para um componente base e

a crosscutting role representa a interface para um aspectual component que afetar´a o componente base. A cl´ausula glue informa se o comportamento crosscutting ir´a afetar antes, depois ou ao redor do comportamento base.

Na Figura 4.19 ´e exibido um exemplo de utiliza¸c˜ao do aspectual connector e a design

rule gerada. Seguindo as regras de mapeamento apresentadas, cada component ´e tradu-

zido para uma structural rule a ser seguida por classes. A intera¸c˜ao entre os componentes ´e representada pelo aspectual connector, o qual ´e traduzido para uma structural rule a ser seguida por aspectos, j´a que estes s˜ao os mecanismos utilizados no modelo orientado a aspectos para modelagem das intera¸c˜oes transversais. A cl´ausula glue informa que o comportamento inserido pelo componente que far´a o papel crosscutting, no exemplo o componente Log, ser´a inserido depois do componente que far´a o papel de base, no exem-

Figura 4.18 Regra de Tradu¸c˜ao da Propriedade requires para sua Design Rule

Figura 4.19 Exemplo de Tradu¸c˜ao de Aspectual Connectors, Base Roles e Crosscutting Roles para sua Design Rule Correspondente

4.1 AS REGRAS DE TRADUC¸ ˜AO 51 plo o componente Server. Na tradu¸c˜ao do aspectual connector ´e necess´ario informar se a porta do componente base ´e provida ou requerida, usando uma das quatro propriedades apresentadas na Se¸c˜ao 4.1.5.

Figura 4.20 Regra de Tradu¸c˜ao de Aspectual Connectors, Base Roles e Crosscutting Roles para sua Respectiva Design Rule com a Propriedade provided

Quando a porta do componente base ´e provida, o designador utilizado pelo conjunto de pontos de jun¸c˜ao ´e o execution, j´a que um servi¸co provido significa que deve existir um ou mais m´etodos que executam um conjunto de opera¸c˜oes para prover esse servi¸co. Em outras palavras, o contexto de interesse ´e o do componente que oferece um servi¸co que ser´a executado. A Figura 4.20 exibe a regra de tradu¸c˜ao quando a porta do componente base possui a propriedade provided. A propriedade provides tamb´em poderia ser utilizada, havendo apenas a substitui¸c˜ao do m´etodo parametrizado pelas assinaturas dos m´etodos contidas em provides.

Caso a porta do componente base seja requerida, um m´etodo ser´a chamado dentro da interface para solicitar um determinado servi¸co, logo o designador utilizado pelo conjunto de pontos de jun¸c˜ao para afetar essa chamada deve ser o call. A Figura 4.21 exibe a regra de tradu¸c˜ao quando a porta do componente base possui a propriedade required. Da mesma forma que na regra anterior, se a propriedade requires for utilizada, tamb´em haver´a a substitui¸c˜ao do m´etodo parametrizado pelas assinaturas dos m´etodos contidas em requires.

Figura 4.21 Regra de Tradu¸c˜ao de Aspectual Connectors, Base Roles e Crosscutting Roles para sua Respectiva Design Rule com a Propriedade required

4.1.7 Representations

A linguagem AspectualAcme d´a suporte a decomposi¸c˜ao hier´arquica de componentes e conectores. Qualquer componente ou conector pode ser representado de forma mais de- talhada atrav´es da utiliza¸c˜ao de representa¸c˜oes. ´E poss´ıvel tamb´em utilizar m´ultiplas representa¸c˜oes para uma mesma entidade arquitetural gerando diferentes vis˜oes para o projetista. Na tradu¸c˜ao para linguagem de especifica¸c˜ao de design rules apenas as repre- senta¸c˜oes de components foram mapeadas. Essa decis˜ao foi tomada devido a tradu¸c˜ao dos

connectors para chamada de m´etodos dos componentes com os quais haver´a intera¸c˜ao,

j´a que esta era a funcionalidade mais comum dos conectores nas arquiteturas modela- das. Al´em disso, tamb´em n˜ao encontramos exemplos na literatura onde a utiliza¸c˜ao de representa¸c˜oes em connectors fosse necess´aria.

A Figura 4.22 exibe um exemplo de tradu¸c˜ao do componente Server que possui a representa¸c˜ao ServerRep. No processo de tradu¸c˜ao ´e informado ao tradutor que essa re- presenta¸c˜ao deve ser considerada. Caso isso n˜ao aconte¸ca, a design rule gerada traduzir´a o componente Server sem considerar sua representa¸c˜ao. O componente Server ´e tradu- zido para uma design rule a ser seguida por interface que servir´a como marca¸c˜ao para informar que todos os componentes da representa¸c˜ao detalham o componente Server. Cada componente da representa¸c˜ao ´e traduzido para uma design rule a ser obedecida por classes e todos eles implementam a structural rule Server. As regras de comunica¸c˜ao entre os componentes da representa¸c˜ao ServerRep s˜ao as mesmas do componente Server com os demais componentes caso n˜ao fosse considerada a representa¸c˜ao. A diferen¸ca ´e que os

4.1 AS REGRAS DE TRADUC¸ ˜AO 53 componentes com os quais Server se comunica ir˜ao referenciar agora os componentes da representa¸c˜ao e estes por sua vez referenciam os componentes externos.

Figura 4.22 Exemplo de Tradu¸c˜ao de Component com Representation para sua Design Rule

A Figura 4.23 ilustra a regra de tradu¸c˜ao de um component com uma representation quando esta ´e selecionada para sua respectiva design rule. O component C ´e traduzido para uma structural rule a ser seguida por interfaces e cada component da representation (C1 e C2) ´e traduzido para uma structural rule a ser obedecida por classes. As regras de comunica¸c˜ao para as ports dos components da representation s˜ao as mesmas das

ports do component externo `as quais elas est˜ao ligados atrav´es da constru¸c˜ao Bindings.

Essa decis˜ao foi tomada porque o mecanismo utilizado para decomposi¸c˜ao hier´arquica no modelo orientado a objetos ´e a agrega¸c˜ao, um caso particular de associa¸c˜ao, que indica que uma das classes do relacionamento est´a contida ou ´e parte de outra classe. Da mesma forma, as representations em AspectualAcme possuem essas mesmas caracter´ısticas.

As propriedades required e provided podem ser utilizadas nos componentes internos `a representa¸c˜ao. Caso uma dessas propriedades seja utilizada numa porta de um compo- nente da representa¸c˜ao, o componente externo tamb´em deve possuir a mesma proprie- dade. Isso ´e necess´ario porque a representa¸c˜ao pode ou n˜ao ser selecionada no processo de tradu¸c˜ao. Por exemplo, usando a regra exibido na Figura 4.23, caso C1 e C2 possu´ıssem

Figura 4.23 Regra de Tradu¸c˜ao de Component com Representation para sua Respectiva De- sign Rule

a propriedade provided o componente externo C tamb´em deve possuir essa mesma pro- priedade.

As propriedades requires e provides tamb´em podem ser utilizadas nos componentes internos `a representa¸c˜ao. Caso uma dessas propriedades seja utilizada numa porta de um componente da representa¸c˜ao, o componente externo tamb´em deve possuir a mesma propriedade. O valor da propriedade do componente externo deve ser um superconjunto da uni˜ao de todos os valores dos componentes internos `a representa¸c˜ao. Assim, usando como exemplo a regra da Figura 4.23, se o componente interno C1 requer um m´etodo m1 e o componente C2 requer o componente m2, ent˜ao a propriedade requires do componente

C deve conter pelo menos os m´etodos m1 e m2. O componente C poderia ainda conter

outros m´etodos que n˜ao fossem requeridos pela representation.