Este Capítulo descreve brevemente os trabalhos relacionados ao tema desta disserta- ção, citando seus pontos positivos e limitações, com relação à abordagem atual.
6.1 FArM (Sochos et al, 2006)
Na abordagem FArM (Feature-Architecture Mapping) (Sochos et al, 2006), o modelo de features é progressivamente refinado, no intuito de enriquecer as informações contidas em suas features.
Nesse refinamento, são definidas quatro transformações: (i) features de que expressam atributos de qualidade e features não relacionadas à arquitetura são „resolvidas‟ a fim de gerar um modelo de features com apenas features funcionais (podendo-se integrar features com outras features, remover features ou adicionar novas features); (ii) features que expressam requisitos arquiteturais difíceis de atender também são „resolvidas‟ com os mesmos critérios que na primeira transformação; (iii) são criadas relações de interação entre as features do mo- delo de features resultante das duas primeiras transformações (em que uma feature usa outra, altera o comportamento de outra ou então contradiz o comportamento de outra) e (iv) são cri- adas relações de hierarquia entra as features (em que subfeatures especializam feature pai, é parte da feature pai ou apresentam alternativas para a feature pai).
Ao longo das transformações, ocorre geração paralela de componentes. Ao final, o ar- quiteto escolhe um estilo arquitetural e esses componentes são adaptados ao estilo escolhido. O método leva em consideração, nessa adaptação, a composição de produto e a flexibilidade da LPS e busca atender essas questões através de uma integração explícita através de meca- nismos de plugin. A feature raiz do modelo de features implementa uma plataforma de cone- xão, em que serão conectados os componentes gerados.
A abordagem trata de uma questão importante, com relação a modelos de requisitos de LPS, uma vez que busca enriquecer o modelo de features que, por si só, carece de informa- ções importantes para definição da arquitetura de LPS. A resolução dos elementos não- arquiteturais e não funcionais, bem como a interação entre features e hierarquia, que são rela- ções específicas de LPS que não podem ser abstraídas, permitem o mapeamento entre requisi- tos e arquitetura.
Em MaRiPLA, resolvemos essa questão usando o modelo orientado a objetivos, que possui maior riqueza de informações que o modelo de features, definindo elementos específi-
cos para requisitos não funcionais e interações entre features, por exemplo. Se houver um modelo de goals definido, o esforço para melhoria do modelo de features é, assim, reduzido.
É importante salientar, porém, que esse enriquecimento do modelo de features realiza- do com o método poderia contribuir para a nossa abordagem, uma vez que o modelo de goals é produzido a partir de modelo de features. Um modelo de features enriquecido poderia gerar um modelo de goals também mais robusto.
Outro aspecto a observar na abordagem FArM, é que não trata dos interesses transver- sais que uma LPS pode apresentar. É importante tratar tais interesses, uma vez que a definição de tais interesses na atividade inicial de requisitos, unida ao mapeamento, facilita a detecção desses interesses na atividade de arquitetura. MaRiPLA utiliza modelo de requisitos e arquite- tural orientados a aspectos, tratando, assim, essa questão.
Por fim, o método FArM é um método ainda manual de mapeamento, que utiliza duas equipes experientes em requisitos e design arquitetural para manipular o modelo de features e descrever os componentes gerados. Ainda há a lacuna de uma ferramenta específica e integra- da, que automatize as transformações. Os autores do trabalho sugerem o uso de diversas fer- ramentas existentes para manipulação dos modelos.
A automatização da ferramenta MaRiPLA, por sua vez, reduz esforço e tempo de de- rivação de arquitetura, gerando a descrição arquitetural a partir de requisitos e permitindo intervenção do arquiteto, caso necessário, para acrescentar ou alterar informações.
6.2 A Metamodeling Approach to Tracing Variability between Requirements and
Architecture in Software Product Lines (Moon et al, 2007)
O trabalho sugere a estratégia de metamodelagem para dar suporte ao rastreamento da variabilidade em requisitos e arquitetura de LPS.
Os autores propõem dois metamodelos, representando requisitos de domínio e arquite- tura de domínio de LPS, com base na Reusable Asset Specification (OMG-RAS, 2005), expli- cam a variabilidade dos elementos de cada metamodelo e, então, definem o rastreamento entre esses dois metamodelos, em um terceiro metamodelo.
Na especificação dos metamodelos, o modelo RAS é estendido, através da adição de novos elementos de modelagem de requisitos (para o metamodelo de requisitos) e de modela- gem arquitetural (para o metamodelo de arquitetura), além de elementos que expressam varia- bilidades.
A partir desses dois metamodelos criados, define-se um terceiro metamodelo, que ex- pressa os links de rastreabilidade entre requisitos e arquitetura, ilustrando graficamente os relacionamentos de dependência entre os artefatos de ambos os metamodelos, e definindo matrizes de rastreabilidade, que fornecem o raciocínio para as decisões de similaridades e variabilidades nos dois modelos e seus artefatos.
A metamodelagem com base em um padrão específico (no caso, o padrão RAS) sim- plifica o rastreameto entre os dois modelos, uma vez que ambos os metamodelos têm um nú- cleo comum, estendendo apenas os elementos específicos de requisitos e arquitetura de LPS. Os metamodelos usados em MaRiPLA, apesar de ambos serem definidos com base em uma mesma tecnologia (ecore-EMF), não apresentam essa mesma similaridade de núcleo (devido à peculiaridade de cada uma das linguagens), o que torna o mapeamento mais complexo.
Outra diferença é que no presente trabalho o mapeamento não se dá por meio de me- tamodelagem, mas são definidas regras de mapeamento precisas, para rastrear elemento a elemento dos metamodelos, além de utilizar DSLs específicas e tecnologias MDD para definir transformações em vários níveis.
Além disso, a mesma tecnologia utilizada em MaRiPLA poderia ser utilizada para descrever os mapeamentos, uma vez que a abordagem ainda não possui uma ferramenta espe- cífica que os suporte e afirma-se que a rastreabilidade apresentada pode ser descrita em OCL (Object Constraint Language) (OMG-OCL, 2012) e diversas ferramentas CASE UML podem avaliar as expressões para reforçar essa rastreabilidade.
6.3 A Model Transformation Approach to Derive Architectural Models from Goal-Oriented Requirement Models (Lucena, 2010)
Este trabalho realiza transformação entre modelo de requisitos orientado a objetivos e descrição arquitetural. O modelo de requisitos é o modelo i* (Yu, 1995) e o modelo arquitetu- ral é a ADL ACME (Garlan et al, 1997).
Na abordagem, é proposto um processo de mapeamento, em que são realizadas três a- tividades principais: (i) análise dos elementos internos do modelo; (ii) definição de regras de transformações horizontais, para lidar com a complexidade inerente a modelos i*, aproximan- do design arquitetural, com a geração de um modelo i* modular e (iii) definição de regras de mapeamento verticais para transformar i* modular em ACME. A arquitetura gerada é refina- da, para incluir os requisitos não funcionais e, por fim, é avaliada com base em métricas de modularidade, comparando soluções arquiteturais obtidas através da abordagem com soluções arquiteturais definidas de forma ad hoc.
A abordagem tem similaridades com o trabalho realizado com MaRiPLA, por tratar da rastreabilidade entre modelo de requisitos orientado a objetivos e descrição arquitetural. É usado o modelo i*, diferente e mais complexo que o PL-AOVgraph que usamos em MaRi- PLA. Porém, essa complexidade é tratada com a definição de regras horizontais.
O trabalho não abrange o universo das LPS, como o MaRiPLA. Por isso, tanto o mo- delo de requisitos como a ADL não são específicos de LPS. Outra diferença com relação a MaRiPLA é que o mapeamento é unidirecional e também não tem um suporte de uma ferra- menta que automatize o processo.
6.4 MaRiSA-MDD (Medeiros, 2008)
MaRiSA-MDD (Medeiros, 2008) é uma ferramenta de mapeamento bidirecional entre requisitos e arquitetura de software, com tecnologias MDD, que transforma especificação textual AOV-Graph em especificação textual AspectualACME e vice-versa.
A ferramenta é executada em plataforma Eclipse e conta com regras de transformação ATL, para transformações modelo a modelo, e o mecanismo TCS (Textual Concrete Syntax) (TCS, 2006), para transformações texto a modelo e modelo a texto.
A arquitetura da ferramenta MaRiPLA (proposta no presente trabalho) é similar à da ferramenta MaRiSA, consistindo aquela ferramenta na extensão desta, pois MaRiSA, apesar de implementar transformações entre modelo de requisitos e descrição arquitetural orientados a aspectos e com tecnologias MDD, não abrange o universo de LPS.
6.5 ReqSys (Santos, 2010) e ReqSys-MDD
O trabalho de Santos (2010) define o modelo de metas PL-AOVgraph, como extensão de AOV-Graph e apresenta ReqSys, que é uma ferramenta que automatiza transformação de modelo de features em modelo de metas PL-AOVgraph. A tecnologia utilizada na implemen- tação da ferramenta é a linguagem de programação Java.
Atualmente, está em andamento um trabalho de migração da ferramenta ReqSys para as tecnologias MDD, o ReqSys-MDD. A proposta realiza transformações bidirecionais entre modelo de features e modelos de metas PL-AOVgraph, nos níveis modelo a modelo, texto a modelo e modelo a texto, de forma similar ao que ocorre em MaRiPLA.
Como ReqSys-MDD será executado apenas no nível de requisitos, os resultados das transformações realizadas na ferramenta poderão ser utilizados como insumos para as trans- formações realizadas em MaRiPLA.