Com relação ao critério de variabilidade, a descrição gerada apresenta os elementos comuns e variáveis, através dos tipos de componentes obrigatórios (Components e Variation- PointT, apresentados na descrição gerada) e pontos de variabilidade (OptionalT e Alternati- veT, apresentados na descrição gerada), que são definidos com base no tipo da contribuição do modelo PL-AOVgraph de origem (capturando tipos de variabilidades and, or, xor, inc-or). Além disso, a arquitetura define relações de dependências entre features, através das restri- ções Armani. Assim, determinamos que esse critério é satisfeito pela arquitetura gerada.
O critério de derivabilidade é, também, atendido em razão do suporte que a arquitetu- ra fornece para derivação de produtos específicos. Os pontos de variação e os componentes obrigatórios gerados são elementos comuns, que serão reusados em cada produto, permitindo essa capacidade de derivação, através de suas portas (Port e/ou VariationPortT).
A reusabilidade pode ser atendida pelo núcleo de elementos comuns da arquitetura. Os componentes obrigatórios e os pontos de variação (VariationPointT) gerados são altamen- te reusáveis, pois são comuns a todos os elementos da LPS. No estudo de caso específico, todos os elementos de primeiro nível da hierarquia são obrigatórios ou pontos de variação. Um exemplo é o ponto de variação Tuner, que é obrigatório e possui quatro variantes opcio- nais (IP, Terrestrial, FileSystem e Satellite). O ponto de variação, nesse caso, é um elemento comum a todos os produtos da LPS, por ser obrigatório, o que permite que o mesmo seja reu- tilizado em cada uma das combinações diferentes de seleção de suas variantes.
Com relação ao atributo corretude, analisamos o atendimento da arquitetura gerada à sua especificação. Nesse quesito, apenas a corretude sintática pode ser garantida, uma vez que a corretude semântica depende de fatores subjetivos, dependendo da interferência do arquiteto (como, por exemplo, com relação à nomeação dos elementos). O modelo gerado é sintatica- mente bem formado, atendendo as regras específicas da linguagem de descrição arquitetural. As subcaracterísticas desse atributo (rastreabilidade e completude) são, também, atendidas, uma vez que são gerados todos os tipos de elementos PL-AspectualACME (completude), como family, system, components, ports, roles, properties, analysis. Cada elemento foi gerado a partir de elementos PL-AOVgraph, e isso contribui com a característica da rastreabilidade, que consiste na capacidade da arquitetura ser mapeada para (ou a partir de) um modelo de outra atividade do ciclo de desenvolvimento. Uma pequena limitação nesse quesito, porém, foi a falta de elementos PL-AOVgraph que gerem conectores comuns de PL-
AspectualACME. No caso do relacionamento transversal, geramos o conector aspectual. Co- nectores comuns, porém, não foram contemplados na transformação, em virtude dessa carên- cia. Com relação aos elementos de PL-AOVgraph que não possuem correspondentes em PL- AspectualACME, estes geraram propriedades (como o operand, do relacionamento transver- sal, por exemplo, que gerou a property operand, no conector aspectual). Com relação à nome- ação de certos elementos,observamos que alguns nomes gerados são extensos, uma vez que a implementação da ferramenta os gera com base nos nomes dos elementos de origem e acres- centando informações que permitem uma melhor identificação. Um exemplo disso são as por- tas geradas, que recebem o nome do componente que as contém, acrescentando-se a String „Port’ (para porta comum) ou „VarPort’ (para porta de variação). O elemento „Conditiona- lAccess’, por exemplo, gerou o componente „ConditionalAcces’ com a porta „ConditionalAc- cessPort’. Apesar de não constituir uma regra específica da linguagem, não é uma boa prática atribuir nomes muito extensos aos elementos de um modelo. Em casos como esse, porém, o arquiteto pode intervir e editar os nomes.
Com relação ao atributo evolutibilidade, observamos que o modelo gerado oferece a possibilidade de intervenção do arquiteto em qualquer momento ou localização da descrição arquitetural, nas possíveis evoluções da LPS. Essa capacidade de evolução é suportada pela (e também suporta a) rastreabilidade, pois evoluções na arquitetura serão incorporadas ao mo- delo de requisitos e vice-versa.
A manutenibilidade também é permitida, de acordo com os mesmos critérios do atri- buto evolutibilidade. O arquiteto pode interferir no modelo gerado no momento que desejar, editando-o e podendo, assim, aplicar as alterações no modelo de requisitos via transformação automatizada na ferramenta MaRiPLA.
Por fim, com relação à representação de elementos transversais, temos o conector as- pectual, com base role, crosscutting role e glue, representando a relação transversal.
5.3 Avaliação da Descrição PL-AOVgraph gerada a partir de PL- AspectualACME
No modelo PL-AOVgraph gerado, a variabilidade é observada a partir dos relacio- namentos de contribuição (and, or, xor, inc-or), que identificam os elementos obrigatórios, opcionais e alternativos da LPS. As restrições entre features são, por sua vez, representadas pelos relacionamentos de correlação do tipo break, entre os elementos hardware e pc e hard- ware e mobile, do estudo de caso.
Os relacionamentos de contribuição também permitem que seja atendido o atributo
derivabilidade, pois elementos com contribuição and (comuns a todos os produtos da LPS)
que possuem filhos com contribuição or, xor ou inc-or, definem a derivação dos produtos específicos.
Da mesma forma que na arquitetura, a reusabilidade pode ser atendida por meio dos elementos do núcleo comum da LPS. Um elemento com contribuição and com filhos or, xor ou inc-or, por exemplo, pode ser reusado em várias configurações diferentes de seus filhos que são variáveis.
Com relação à corretude, observamos que os elementos gerados de PL-AOVgraph es- tão todos exatamente em conformidade com sua semântica. Tanto os elementos quanto os relacionamentos foram gerados com localização exata e na hierarquia correta.
É possível que uma arquitetura descrita do zero, ou a partir de um modelo de requisi- tos diferente do modelo de metas, não contemple todos os elementos que são definidos neste tipo de modelo. Assim, na análise da completude, que é sub-atributo da corretude, PL- AOVgraph gerado de PL-AspectualACME contempla todos os elementos específicos do es- tudo de caso Ginga ForAll. Componentes de PL-AspectualACME foram transformados em tasks e a contribuição (and, or, xor, inc-or) é definida pelo tipo de componente (obrigatório, alternativo, opcional, inclusive-or). A partir das restrições Armani, foram geradas correlações entre elementos e a partir do conector aspectual, foi gerado um relacionamento transversal. Não houve geração de goals nem de softgoals, uma vez que a arquitetura descrita do zero não define esse tipo de elemento. No trecho de descrição do Ginga ForAll usado, de toda forma, temos apenas tasks. Se houvesse tais elementos, os mesmos seriam gerados caso a descrição arquitetural de entrada fosse criada a partir de um PL-AOVgraph ou por um arquiteto que conhecesse o modelo de metas e representasse esses tipos nas propriedades dos componentes. No relacionamento transversal, não são gerados elementos como Intertype Declarations, at- tributtes ou elements. Isso ocorre, também, por a arquitetura ser gerada do zero (sem definição das propriedades), mas de qualquer forma, o estudo de caso não contempla tais elementos (que estariam representados, também, em propriedades da arquitetura). O mesmo ocorre com os diversos tipos de propriedades de PL-AOVgraph.
Com relação à rastreabilidade, que é outro sub-atributo da corretude, conseguimos definir correspondências relativamente precisas entre os elementos de PL-AspectualACME e PL-AOVgraph. Houve uma dificuldade, porém, nesse aspecto, em virtude do metamodelo de PL-AOVgraph possuir uma quantidade de elementos superior à quantidade de elementos do metamodelo de PL-AspectualACME. O relacionamento transversal de PL-AOVgraph é repre-
sentado com uma riqueza maior de detalhes do que a descrição arquitetural. A rastreabilida-
de, nesse caso, é garantida por meio das propriedades de PL-AspectualACME, bem como
pela possibilidade da linguagem ATL de permitir geração de vários elementos a partir de um único. Isso nos permite afirmar que a ferramenta define um modelo de rastreabilidade simpli- ficado, uma vez que as propriedades permitem identificar o elemento de origem. Um conector aspectual de PL-AspectualACME, por exemplo, possui os elementos BaseRole, Crosscuttin- gRole e Glue. A partir desse conector, porém, devemos gerar um relacionamento transversal com advice (com joinPointAdvice e advice category) e pointcut (com operand, operator e JoinPointPointcut) em PL-AOVgraph. Além disso, há as Intertype Declarations, com Ele- ments e Attributes. Como representar tantos elementos e sub-elementos a partir de um simples conector? A Figura 30 ilustra essa possibilidade.
Figura 30: Rastreamento do Conector Aspectual de PL-AspectualACME para o relacionamento transversal de PL-AOVgraph
O conector aspectual gerou o relacionamento transversal. Durante a transformação, fo- ram criados os elementos Advice e Pointcut (a regra ATL gera o elemento e permite criar, internamente, os seus sub-elementos). Intertype Declaration seria gerado a partir de uma pro- priedade específica do conector (não foi gerado, por não ser contemplado no estudo de caso). Advice Category foi gerado a partir da Glue do conector, pois ambos representam o tipo do advice no relacionamento transversal (around, before ou after). JoinPoint Pointcut é referente ao elemento ao qual o BaseRole está conectado. Operand e Operator, por sua vez, são gerados a partir de propriedades do BaseRole. Por fim, JoinPoint Advice é gerado a partir do elemento ao qual o CrosscuttingRole se liga.
Os atributos evolutibilidade e manutenibilidade são garantidos, na descrição PL- AOVgraph gerada, pelas mesmas razões que em PL-AspectualACME. A descrição é gerada em um editor em que o engenheiro é livre para acrescentar ou alterar as informações que de-
sejar (dentro das regras específicas da linguagem), podendo, então, re-executar as transforma- ções, transferindo as alterações ou acréscimos à arquitetura.
É importante salientar que as descrições geradas foram avaliadas subjetivamente, uma vez que o modelo de qualidade não define métricas, mas apenas atributos de qualidade especí- ficos.