UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA
PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO
Dissertação de Mestrado
ReqSys-MDD: Uma Ferramenta para Mapeamento
entre Modelos de Features e Requisitos em Linhas de
Produto de Software
Lidiane Oliveira dos Santos Sousa
LIDIANE OLIVEIRA DOS SANTOS SOUSA
ReqSys-MDD: Uma Ferramenta para Mapeamento
entre Modelos de Features e Requisitos em Linhas de
Produto de Software
Dissertação de Mestrado submetida ao programa de Pós-Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito para a obtenção do título de Mestre em Sistemas e Computação.
Profª. Drª. Thaís Vasconcelos Batista
Orientadora
Profª. Drª. Lyrene Fernandes da Silva
Co-Orientadora
Dissertação de Mestrado, sob o título “ReqSys-MDD: Uma Ferramenta para Mapeamento entre Modelos de Features e Requisitos em Linhas de Produto de Software”, submetida à banca examinadora como requisito para a obtenção do título de Mestre em Sistemas e Computação da Universidade Federal do Rio Grande do Norte.
_______________________________________________________ Profa. Dra. Thaís Vasconcelos Batista
Departamento de Informática e Matemática Aplicada - UFRN
________________________________________________________ Profa. Dra. Lyrene Fernandes da Silva
Departamento de Informática e Matemática Aplicada - UFRN
_______________________________________________________ Profa. Dra. Sergio Castelo Branco Soares
Agradecimentos
A sensação de dever cumprido é, sem dúvida, uma das mais gratificantes. Estou imensamente feliz por ter concluído mais uma etapa da minha vida. Por isso, quero expressar meus sinceros agradecimentos àqueles que, de alguma forma, contribuíram para a elaboração deste trabalho.
Primeiramente agradeço a Deus por me permitir chegar até aqui. Por me capacitar e me conduzir em toda minha trajetória.
A minha orientadora Thaís e minha co-orientadora Lyrene por compartilharem comigo suas experiências, pela disponibilidade em esclarecer as dúvidas que surgiam e pelo acompanhamento de cada etapa do desenvolvimento deste trabalho.
Aos meus pais Elza e Humberto. Reconheço que sem os esforços de vocês eu não teria chegado até aqui! Também ao meu irmão, Wagner, pelo apoio.
Ao meu esposo Francisco pelo companheirismo, pelas palavras de conforto, por não medir esforços em me ajudar e por tornar melhores os meus dias.
A Roberta pelas sugestões que contribuíram para tornar este trabalho mais sólido. Aos meus colegas de mestrado que muito me ajudaram e prontamente aceitaram participar do experimento controlado realizado neste trabalho, Lucas, Keivilany, Ana Luisa, Eduardo, Maíra e Larissa.
A Thiago pela amizade, incentivo e contribuições.
A instituição UFRN e seus professores pelo ensino e aprendizado. A CAPES pelo apoio financeiro despendido a este trabalho.
Resumo
A abordagem de Linha de Produto de Software (LPS) tem se tornado bastante promissora nos dias de hoje, uma vez que permite a produção de sistemas customizados em larga escala, através de famílias de produtos. Para a modelagem destas famílias o Modelo de Features tem sido muito utilizado, no entanto, se trata de um modelo que apresenta baixo nível de detalhamento, podendo não ser suficiente para orientar a equipe de desenvolvimento da LPS. Dessa forma, é recomendável agregar o Modelo de Features a outros modelos que representem o sistema sob outras perspectivas. O Modelo de Metas PL-AOVgraph pode assumir esta função complementar ao Modelo de Features, uma vez que possui uma linguagem voltada para o contexto das LPS’s, que permite a modelagem de requisitos de forma detalhada e a identificação de características transversais, que podem surgir em decorrência da variabilidade. Com o objetivo de inserir PL-AOVgraph no processo de desenvolvimento das LPS’s, este trabalho propõe um mapeamento bi-direcional entre PL-AOVgraph e Modelo de Features, que será automatizado pela ferramenta ReqSys-MDD. Esta ferramenta utiliza a abordagem de Desenvolvimento Orientado a Modelos (Model-Driven Development – MDD), que permite a construção de sistemas a partir de modelos de alto nível, através de transformações sucessivas. Isto possibilita a integração de ReqSys-MDD com outras ferramentas MDD que utilizem seus modelos de saída como entrada para outras transformações. Assim, é possível manter a consistência entre os modelos envolvidos, evitando a perda de informações nas transições entre as etapas de desenvolvimento.
Palavras-chave: Linha de Produto de Software, Modelo de Features, PL-AOVGraph,
Abstract
The approach Software Product Line (SPL) has become very promising these days, since it allows the production of customized systems on large scale through product families. For the modeling of these families the Features Model is being widely used, however, it is a model that has low level of detail and not may be sufficient to guide the development team of LPS. Thus, it is recommended add the Features Model to other models representing the system from other perspectives. The goals model PL-AOVgraph can assume this role complementary to the Features Model, since it has a to context oriented language of LPS's, which allows the requirements modeling in detail and identification of crosscutting concerns that may arise as result of variability. In order to insert PL-AOVgraph in development of LPS's, this paper proposes a bi-directional mapping between PL-AOVgraph and Features Model, which will be automated by tool ReqSys-MDD. This tool uses the approach of Model-Driven Development (MDD), which allows the construction of systems from high level models through successive transformations. This enables the integration of ReqSys-MDD with other tools MDD that use their output models as input to other transformations. So it is possible keep consistency among the models involved, avoiding loss of informations on transitions between stages of development.
Keywords: Software Product Line, Features Model, PL-AOVGraph, ReqSys-MDD,
Sumário
1. Introdução ... 14
1.1. Motivação ... 16
1.2. Objetivos... 17
1.3. Estrutura do trabalho ... 18
2. Fundamentação Teórica... 20
2.1. Linhas de Produto de Software e Modelos de Features ... 20
2.2. O Modelo de Metas PL-AOVgraph... 22
2.3. MDD (Model-Driven Development) ... 27
2.4. ATL (Atlas Transformation Language) ... 29
3. Mapeamento entre PL-AOVgraph e Modelo de Features ... 31
3.1. Processo ... 31
3.2. Mapeamento entre PL-AOVgraph e Modelo de Features ... 32
3.2.1. Mapeamento de PL-AOVgraph para Modelo de Features ... 33
3.2.2. Mapeamento de Modelo de Features para PL-AOVgraph ... 37
3.2.3. Restrições do Mapeamento... 40
3.3. Regras Complementares ... 41
4. ReqSys-MDD ... 47
4.1. Visão Geral da Ferramenta ... 47
4.2. ReqSys-MDD X ReqSys ... 49
4.3. Implementação das Regras de Mapeamento ... 50
4.4. XFeature ... 54
5. Estudo de Caso ... 57
5.1. Smart Home ... 57
5.2. Etapas do Estudo de Caso... 57
5.2.1. Primeira Etapa (PL-AOVgraph → Modelo de Features) ... 59
5.2.2. Segunda Etapa (Modelo de Features → PL-AOVgraph) ... 62
5.2.3. Análise Geral ... 66
6. Experimento Controlado ... 67
6.1. Planejamento ... 67
6.1.1. Objetivo ... 67
6.1.2. Questões, Métricas e Hipóteses ... 67
6.1.4. Variáveis ... 70
6.1.5. Contexto do Experimento... 70
6.1.6. Ameaças a Validade ... 71
6.2. Execução do Experimento ... 71
6.2.1. Modelos de Entrada ... 72
6.2.2. Tabela de Mapeamento... 72
6.2.3. Relatório ... 73
6.3. Resultados... 73
6.3.1. Experimento 1 – Transformação Manual ... 73
6.3.2. Experimento 1 – Transformação Automática... 76
6.3.3. Experimento 2 – Transformação Manual ... 78
6.3.4. Experimento 2 – Transformação Automática... 80
6.4. Análise dos Resultados... 81
6.4.1 Duração... 81
6.4.2. Rastreabilidade ... 82
6.4.3. Verificação das Hipóteses ... 83
6.4.4. Considerações Finais do Experimento Controlado ... 84
7. Trabalhos Relacionados... 86
7.1. RDL (Requirements Description Language) e VML4RE (Variability Modeling Language for Requirements) ... 86
7.2. G2SPL: Um Processo de Engenharia de Requisitos Orientada a Objetivos para Linhas de Produtos de Software ... 88
7.3. MaRiSA-MDD (Mapping Requirements to Software Architecture – Model-Driven Development)... 90
7.4. Comparativo entre Abordagens ... 93
8. Conclusão ... 95
8.1. Contribuições... 95
8.2. Trabalhos Futuros ... 96
Referências ... 97
Apêndice A – XMI da especificação PL-AOVGraph de Smart Home ... 101
Apêndice B – XMI do Modelo de Features de Smart Home ... 105
Apêndice C – Regras ATL - PL-AOVGraph Modelo de Features ... 109
Lista de Figuras
Figura 1. Atividades essenciais para uma Linha de Produto de Software... 21
Figura 2. Modelo de Features de ECommerce... 22
Figura 3. Elementos e relacionamentos de PL-AOVgraph (Representação gráfica) ... 23
Figura 4. Relacionamentos de contribuição em PL-AOVgraph (a) Modo gráfico; (b) Modo textual ... 24
Figura 5. Relacionamento de correlação em PL-AOVgraph (a) Modo gráfico; (b) Modo textual ... 24
Figura 6. Relacionamento transversal em PL-AOVgraph (a) Modo gráfico; (b) Modo textual ... 25
Figura 7. Propriedades de PL-AOVgraph para suporte a cardinalidade ... 27
Figura 8. Principais elementos do MDD ... 28
Figura 9. Processo de transformação de Author para Person... 29
Figura 10. Transformação ATL de Author para Person... 30
Figura 11. Processo de mapeamento entre PL-AOVgraph e Modelo de Features ... 31
Figura 12. Processo de mapeamento entre PL-AOVgraph e PL-AspectualACME ... 32
Figura 13. Especificação PL-AOVgraph parcial de Smart Home ... 34
Figura 14. Modelo de Features obtido a partir da especificação PL-AOVgraph da Figura 13 ... 34
Figura 15. Trecho da especificação PL-AOVgraph de ECommerce... 36
Figura 16. Modelo de Features obtido a partir da especificação PL-AOVgraph da Figura 15 ... 36
Figura 17. Modelo de Features parcial de Smart Home... 37
Figura 18. Especificação PL-AOVgraph obtida a partir do Modelo de Features da Figura 17 ... 38
Figura 19. Trecho da especificação PL-AOVgraph obtida a partir do Modelo de Features da Figura 14 ... 39
Figura 20. Mapeamento entre tipos de elementos PL-AOVgraph e anotações no Modelo de Features ... 42
Figura 21. Mapeamento entre Intertype Declarations Element e Features ... 43
Figura 23. Mapeamento envolvendo Advices Before ou After e Features de Referência ... 45
Figura 24. Arquitetura de ReqSys-MDD... 47
Figura 25. Fluxo da transformação de PL-AOVgraph para Modelo de Features em ReqSys-MDD... 48
Figura 26. ReqSys-MDD em funcionamento ... 48
Figura 27. Arquitetura de ReqSys ... 49
Figura 28. Fluxo da transformação de PL-AOVgraph para Modelo de Features em ReqSys. 50 Figura 29. Metamodelo de PL-AOVgraph ... 51
Figura 30. Metamodelo do Modelo de Features ... 51
Figura 31. Visão parcial dos modelos de entrada para as transformações ATL no “Sample Reflective Ecore Model Editor” – (A) PL-AOVgraph de Smart Home; (B) Modelo de Features de Smart Home ... 52
Figura 32. Regra 3 do mapeamento de PL-AOVgraph para Modelo de Features em ATL .... 53
Figura 33. Regra 3 do mapeamento de Modelo de Features para PL-AOVgraph em ATL .... 54
Figura 34. Modelo de Features de ECommerce modelado através da ferramenta XFeature... 55
Figura 35. Modelo de Features parcial de Smart Home em XFeature... 56
Figura 36. Anotação em XFeature... 56
Figura 37. Etapas do Estudo de Caso ... 58
Figura 38. Especificação PL-AOVgraph de Smart Home... 60
Figura 39. Modelo de Features de Smart Home gerado por ReqSys-MDD ... 61
Figura 40. Especificação PL-AOVgraph gerada por ReqSys-MDD a partir do Modelo de Features produzido na transformação anterior... 62
Figura 41. Modelo de Features de Smart Home ... 63
Figura 42. Especificação PL-AOVgraph de Smart Home gerada por ReqSys-MDD ... 64
Figura 43. Modelo de Features gerado por ReqSys-MDD a partir da Especificação PL-AOVgraph produzida na transformação anterior ... 65
Figura 44. Relatório do Experimento ... 73
Figura 45. Modelo de Features produzido manualmente a partir de PL-AOVgraph... 74
Figura 46. Modelo de Features gerado automaticamente a partir de PL-AOVgraph por ReqSys-MDD ... 77
Figura 47. Especificação PL-AOVgraph produzida manualmente a partir do Modelo de Features ... 79
Lista de Tabelas
Tabela 1. Elementos de PL-AOVgraph X elementos do Modelo de Features ... 33
Tabela 2. Regras de transformação de PL-AOVgraph para Modelo de Features... 33
Tabela 3. Regras de transformação de Modelo de Features para PL-AOVgraph... 37
Tabela 4. Regras complementares para o mapeamento de PL-AOVgraph para Modelo de Features ... 41
Tabela 5. Regras complementares para o mapeamento de Modelo de Features para PL-AOVgraph ... 41
Tabela 6. Relação entre os grupos e as etapas do experimento... 70
Tabela 7. Fases do Experimento Controlado... 71
Tabela 8. Resumo do Mapeamento entre PL-AOVgraph e Modelo de Features ... 72
Tabela 9. Duração das Etapas do Experimento ... 82
1.
Introdução
À medida que as indústrias de software aumentam a capacidade de produção, cresce também a demanda por sistemas mais complexos e de maior qualidade. Neste contexto, tem-se no reuso uma forma de reagir rapidamente a estas mudanças, buscando o aumento da qualidade, produtividade e diminuição de custos no desenvolvimento do software (Atkinson et al, 2002). O reuso permite o reaproveitamento de todas as formas de experiências, incluindo produtos, processos, documentação e até modelos de qualidade e de produtividade.
Neste cenário de reuso que surgiu a idéia de Linha de Produto de Software (LPS), que permite a reutilização não só do código, mas também de outros artefatos como arquitetura e requisitos de forma sistemática, tendo como base as linhas de produção industriais (Berg et al, 2005). Uma LPS é um conjunto de produtos (software) que compartilham muitas propriedades comuns, mas também variam em certas propriedades específicas para atender um segmento particular de mercado.
As LPS’s permitem o desenvolvimento de aplicações personalizadas em larga escala, agrupando os produtos em famílias que possuem características comuns e variáveis (Clements et al, 2001). As características comuns aparecem em todos os produtos da família e compõem a infra-estrutura da LPS, denominada core assets. As características variáveis permitem a customização dos produtos e são denominadas variabilidades.
Quanto maior o grau de variabilidade, maiores são as possibilidades de personalização dos produtos, porém dificulta o gerenciamento da LPS. Por este motivo, é fundamental o gerenciamento da variabilidade nas LPS’s.
O Modelo de Features (Czarnecki et al, 2005b) é atualmente a proposta mais utilizada para representação de LPS’s, contribuindo para o gerenciamento da variabilidade, uma vez que facilita a identificação dos componentes reusáveis e configuráveis, através da visualização das features e da variabilidade. O Modelo de Features ainda pode ser utilizado para negociar as funcionalidades do software junto ao cliente, devido a sua simplicidade e ao baixo nível de detalhamento. Porém, este nível de detalhamento omite determinadas informações sobre os requisitos do sistema (Silva et al, 2010b).
ser suficientes para orientar a equipe de desenvolvimento. Por este motivo, é recomendável que o Modelo de Features seja agregado a outros modelos, para permitir uma base de conhecimento adequado para o desenvolvimento da LPS, com diferentes visões do sistema (Neiva, 2008).
O Modelo de Metas AOV-graph (Silva, 2006) consiste em um forte candidato para atuar junto com o Modelo de Features na modelagem de LPS’s, pois além de herdar todas as funcionalidades do Modelo de Metas V-Graph (Yu et al, 2004), utiliza os conceitos de orientação a aspectos (Filman et al, 2005), incluindo um novo tipo de relacionamento, denominado “relacionamento transversal”. Este relacionamento permite realizar a separação e a composição de características transversais a nível de requisitos, conferindo uma maior modularização ao modelo. Características transversais são aquelas que se relacionam intensamente, de forma que a dependência entre elas as leva a influenciar ou restringir umas às outras.
O tratamento destas características é importante no contexto de LPS, uma vez que a variabilidade das LPS’s pode afetar vários produtos, podendo resultar em características transversais. Com AOV-Graph estas características podem ser identificadas nas etapas iniciais do desenvolvimento, sendo levadas em consideração logo na elaboração dos requisitos, influenciando desde os primeiros produtos. Porém, Santos (2010) constatou que AOV-Graph não é suficiente para representar variabilidades, depois de apresentar algumas inconsistências diante da modelagem de determinadas LPS’s. Por exemplo, em alguns casos a variabilidade é representada através de cardinalidade, e AOV-Graph não permite a atribuição de cardinalidade a requisitos nem a grupos de requisitos. Sendo assim, Santos (2010) propôs o Modelo de Metas PL-AOVgraph.
PL-AOVgraph é uma extensão de AOV-Graph voltado para o contexto das LPS’s, que mantém tanto informações de requisitos quanto informações de variabilidade. PL-AOVgraph não substitui, mas complementa o Modelo de Features, detalhando requisitos, identificando e separando características transversais, enquanto o Modelo de Features encarrega-se de representar as features relevantes para a delimitação do domínio das famílias de produtos.
1.1. Motivação
O mapeamento implementado por Santos (2010) possui algumas limitações que podem causar inconsistências nos modelos produzidos por ReqSys em determinados casos. Por exemplo, no mapeamento de Modelo de Features para PL-AOVgraph cada feature é convertida em uma task, assim, goals e softgoals nunca são gerados, enquanto no mapeamento de PL-AOVgraph para Modelo de Features não são representados os advices dos tipos before e after, intertype declarations, pointcuts com primitiva substitute e operador or. Além disso, esta abordagem não visa atingir outros níveis de desenvolvimento, limitando-se apenas ao nível dos requisitos. Seria relevante limitando-se o mapeamento entre modelos limitando-se estendesse, permitindo a criação de outros modelos de diferentes níveis de abstração. Isto é possível através do Desenvolvimento Orientado a Modelos (Model-Driven Development – MDD) (Stahl et al, 2006).
O Desenvolvimento Orientado a Modelos é uma abordagem que permite a utilização sistemática de modelos na especificação e implementação de um sistema. O MDD possibilita a geração de código-fonte a partir de modelos com alto nível de abstração, através de transformações sucessivas até se chegar ao código. Além de vantagens como a redução do tempo de desenvolvimento e reuso, com as transformações entre modelos é possível reduzir a perda de informações na passagem de uma etapa de desenvolvimento para outra, mantendo uma espécie de rastreamento entre os artefatos do sistema. Com isso, as modificações realizadas nos modelos propagam-se gradativamente até o código.
Diante das inúmeras vantagens proporcionadas pela abordagem MDD, este trabalho propõe ReqSys-MDD – um plug-in para o ambiente Eclipse que implementa as regras de mapeamento entre PL-AOVgraph e Modelo de Features definidas por Santos (2010), juntamente com novas regras complementares para aperfeiçoar o mapeamento e resolver as limitações supracitadas, através do MDD.
Ao adotar a abordagem MDD, é possível reutilizar o modelo produzido por uma transformação, como entrada para outras transformações. Por exemplo, na transformação de Modelo de Features para PL-AOVgraph, é possível utilizar a especificação PL-AOVgraph gerada como entrada para o mapeamento proposto por (Coelho, 2012) entre PL-AOVgraph e PL-AspectualACME (Batista et al, 2009), uma linguagem de descrição arquitetural voltada para as LPS’s. Dessa forma, mapeia-se do modelo de requisitos para o modelo arquitetural.
consistência entre todos os modelos envolvidos. Um trabalho relacionado realizado neste sentido foi o projeto MaRiSA-MDD (Medeiros, 2008), que emprega técnicas do desenvolvimento orientado a modelos para realizar o mapeamento entre modelos de requisitos, descrição arquitetural e projeto detalhado. Porém, o projeto não é voltado para o contexto das LPS’s
1.2. Objetivos
Este trabalho tem como objetivo principal aperfeiçoar a integração das abordagens orientada a metas e orientada a features, através do refinamento do mapeamento bi-direcional proposto por Santos (2010), entre as linguagens PL-AOVgraph e Modelo de Features. Além disso, disponibilizar uma ferramenta que permite a automação do processo de transformação, denominada ReqSys-MDD, através de técnicas e ferramentas do Desenvolvimento Orientado a Modelos (MDD). Além disso, é objetivo desse trabalho avaliar se ReqSyS-MDD proporciona ganhos, no processo de desenvolvimento envolvendo o modelo de features e o modelo de requisitos, relacionados ao tempo de produção dos modelos, a completude e a rastreabilidade entre os modelos.
ReqSys-MDD pode ser considerada uma ferramenta auxiliar de desenvolvimento, que não tem como objetivo prover uma solução para substituir o Engenheiro de Software no processo de desenvolvimento. O Engenheiro deverá usar o modelo de requisitos produzido por ReqSys-MDD e aperfeiçoá-lo. ReqSys-MDD visa evitar o grande esforço do engenheiro em produzir todo o modelo de requisitos e ainda mantê-lo em conformidade com o Modelo de Features.
Para a implementação deste mapeamento utilizamos o ambiente Eclipse (Eclipse, 2011), juntamente com o EMF (Eclipse Modeling Framework) (EMF, 2011), onde utilizamos o metametamodelo Ecore para a descrição dos metamodelos de PL-AOVgraph e do Modelo de Features. Para a especificação das regras de transformação usamos a linguagem ATL (ATLAS Transformation Language) (Atlas, 2003) e para as transformações de texto para modelo e de modelo para texto utilizamos, respectivamente, os plug-ins XText (XText, 2011) e Acceleo (Acceleo, 2011).
Os objetivos específicos deste trabalho são:
• Definição de regras de mapeamento entre PL-AOVgraph e Modelo de Features complementares às regras definidas por Santos (2010);
• Implementação das regras de mapeamento utilizando a linguagem de transformação ATL;
• Elaboração de dois parsers através do plug-in XText: um para transformar Modelos de Features, escritos em XML (OMG/XML, 2011), em modelos XMI; e outro para transformar especificações textuais PL-AOVgraph em modelos XMI;
• Elaboração de dois parsers através do plug-in Acceleo: um para transformar modelos XMI em Modelos de Features, escritos em XML; e outro para transformar modelos XMI em especificações textuais PL-AOVgraph;
• Implementação de um editor de especificações PL-AOVgraph, através do plug-in XText;
• Definição dos modelos de entrada para as transformações;
• Avaliação das regras de mapeamento e da ferramenta ReqSys-MDD através do estudo de caso Smart Home (Sánchez et al, 2007), onde apresentados os resultados de uma sequência de transformações envolvendo a especificação PL-AOVgraph e o Modelo de Features de Smart Home, e de um experimento controlado, onde alunos de graduação e pós-graduação utilizaram na prática a ferramenta proposta.
1.3. Estrutura do trabalho
2.
Fundamentação Teórica
Este capítulo apresenta os principais conceitos envolvidos neste trabalho. A seção 2.1 descreve os conceitos de Linhas de Produto de Software e Modelos de Features; a seção 2.2 apresenta o Modelo de Metas PL-AOVgraph, uma linguagem de modelagem de requisitos com suporte a aspectos e variabilidade; a seção 2.3 introduz o conceito de Desenvolvimento Orientado a Modelos (MDD); por fim, a seção 2.4 apresenta a linguagem de transformação ATL.
2.1. Linhas de Produto de Software e Modelos de Features
As Linhas de Produto de Software (LPS) permitem a reutilização sistemática de software, através do desenvolvimento de famílias de produtos que compartilham aspectos comuns, prevendo suas peculiaridades (Berg et al, 2005). As diferenças entre os produtos são denominadas variabilidades. O nível de variabilidade determina a capacidade de um sistema ser personalizado de acordo com um contexto específico, possibilitando a produção de produtos em larga escala.
As similaridades presentes nas famílias de produtos permitem o reuso não apenas do código, mas principalmente da arquitetura, da tecnologia, dos requisitos, e de outros artefatos, que por serem genéricos só precisam ser desenvolvidos uma única vez, e não uma vez para cada produto. Consequentemente, se os produtos apresentarem erros em comum, a manutenção pode ser efetuada em um único artefato, o que não acontece quando se faz reuso de código sem um planejamento, sendo necessário alterar cada produto (Castro, 2008). Tudo isso reflete na diminuição dos custos de desenvolvimento, no aumento da qualidade e na redução do tempo de entrega.
intensifica ainda mais a interação entre as atividades. O gerenciamento deve ser realizado sempre, para manter o controle de todo o processo.
Figura 1. Atividades essenciais para uma Linha de Produto de Software
Fonte: (Clements et al, 2001)
Para obter um melhor entendimento e gerenciamento da variabilidade é interessante projetar alguma forma de modelagem da LPS. A proposta mais utilizada para representar graficamente as linhas de produto é o Modelo de Features, que inicialmente foi proposto como parte do método Feature-Oriented Domain Analysis – FODA (Kang et al, 1990), e desde então tem sido aplicado em diversos domínios. Este modelo é capaz de representar as variabilidades e as dependências entre as features da LPS. Uma feature é uma abstração, podendo ser, por exemplo, um requisito, uma funcionalidade, uma parte ou apenas uma característica do produto, desde que seja relevante para algum stakeholder (pessoa interessada e que interage com o sistema de alguma forma).
O modelo de features possui a estrutura de uma árvore, onde a raiz representa o contexto do modelo, os nós representam as features e as arestas indicam os relacionamentos. As features podem ser classificadas como obrigatórias (devem estar presentes em todos os produtos da família), opcionais (podem ou não estar presentes em um determinado produto), alternativas (em um agrupamento de features exatamente uma delas deve fazer parte do produto) e inclusive-or (em um agrupamento de features um subconjunto do grupo deve fazer parte do produto).
e quantas features pertencentes a um grupo podem ser selecionadas. Atributos permitem que as features possuam um valor em cada instância do modelo de features. As anotações permitem que o usuário adicione propriedades às features, alterando diretamente o metamodelo.
A Figura 2 apresenta um exemplo de modelo de features onde podemos observar sua estrutura e notação, conforme a legenda. Trata-se se um sistema de comércio eletrônico, onde a feature “ECommerce” é a raiz do modelo de features e representa o contexto da LPS. A feature “Payment” é um exemplo de feature obrigatória e possui uma sub-feature opcional chamada “PaymentTypes”. Esta por sua vez, possui um agrupamento inclusive-or, composto pelas sub-features “DebitCard”, “PurshaseOrder” e “CreditCard”. A feature “Expiration” possui um agrupamento com as features alternativas “InDay(Int)” e “Never”. A feature “Chars” também possui um agrupamento, mas este possui cardinalidade, indicando que no mínimo 2 e no máximo 4 dos membros do grupo devem aparece no produto final. A feature “Method(String)” é uma feature com cardinalidade, mas não deixa de ser obrigatória, uma vez que sua cardinalidade mínima é 1.
Figura 2. Modelo de Features de ECommerce
Fonte: Adaptado de (Czarnecki et al, 2005a)
2.2. O Modelo de Metas PL-AOVgraph
Modelos de metas são grafos hierárquicos capazes de modelar requisitos funcionais, não funcionais e regras de negócio de um sistema, através da decomposição de metas que torna explícita a razão pela qual as submetas são necessárias (Giorgini, 2002; Yu, 2004).
funcionalidades de AOV-Graph, inclusive o suporte a orientação a aspectos através da separação de características transversais. PL-AOVgraph permite a modelagem de requisitos na forma textual e gráfica.
Os elementos de PL-AOVgraph, assim como os de AOV-Graph, podem ser classificados em: (i) task (tarefa): requisito funcional; (ii) softgoal (softmeta): requisito não funcional; e (iii) goal (meta): objetivo organizacional. PL-AOVgraph herda três tipos de relacionamentos de AOV-Graph, que são: contribuição, correlação e transversal. A Figura 3 mostra a representação gráfica destes elementos e relacionamentos.
Figura 3. Elementos e relacionamentos de PL-AOVgraph (Representação gráfica)
Fonte: (Santos, 2010)
O relacionamento de contribuição representa a associação de elementos (task/goal/softgoal) filhos dentro de um elemento pai. PL-AOVgraph herda de AOV-Graph os seguintes tipos de contribuição:
• And: Elemento obrigatório para a concretização do elemento pai;
• Or: Elemento opcional para a concretização do elemento pai;
• Xor: Apenas um dos elementos com este tipo de relacionamento deve ser satisfeito para que o elemento pai também seja.
Além destes relacionamentos de contribuição, PL-AOVgraph adiciona a contribuição inc-or, que indica que no mínimo um e no máximo todos os elementos com este tipo de relacionamento devem ser satisfeitos para que o elemento pai também seja.
“PaymentTypes” também seja. As tasks “InDay” e “Never” possuem contribuição xor, indicando que exatamente uma delas deve ser satisfeita para a concretização de “Expiration”.
Figura 4. Relacionamentos de contribuição em PL-AOVgraph (a) Modo gráfico; (b) Modo textual
O relacionamento de correlação indica a influência, positiva ou negativa, que um determinado requisito pode exercer sobre outro, sendo classificado como:
• Make: Um requisito só existe se o outro existir;
• Break: Um requisito impossibilita a existência do outro;
• Help: Um requisito reforça o outro;
• Hurt: Um requisito afeta o outro;
• Unknown: Existe a influencia, mas não é possível determinar se esta é positiva ou negativa.
Na Figura 5 temos um exemplo de relacionamento de correlação do tipo make, nos modos gráfico e textual. Neste caso, a goal “Authentication”, que é a origem do relacionamento, requer a softgoal “Confidentiality”, que é o destino. Isto significa que para garantir que informações confidenciais sejam acessadas somente por pessoas autorizadas é necessário um mecanismo de autenticação.
O relacionamento transversal permite a modularização de requisitos espalhados e entrelaçados entre si, reduzindo a quantidade de relacionamentos entre tasks, goals e softgoals, uma vez que muitas interações são condensadas em poucos relacionamentos transversais (Silva, 2006).
Este relacionamento baseia-se nos elementos do Desenvolvimento de Software Orientado a Aspectos (DSOA) propostos pela linguagem de programação AspectJ: (i) Source: É a origem do relacionamento, ou seja, o requisito que irá afetar outro(s) requisito(s); (ii) Pointcuts: Conjunto de destinos do relacionamento, ou seja, os componentes que serão afetados no relacionamento transversal; (iii) Advices: Especifica quais dos filhos de source se espalham e se entrelaçam aos pointcuts. Podem ser dos tipos before, around e after indicando, respectivamente, pré-condição, decomposição e pós-condição do elemento em relação ao pointcut; (iv) Intertype Declarations: Adiciona um novo tipo de elemento ao modelo de metas, que pode ser dos tipos: Attribute: Representa um atributo; e Element: Representa um elemento (task, goal ou softgoal).
A Figura 6 traz um exemplo de relacionamento transversal, nos modos gráfico e textual. O elemento source é a goal “Persistence”, isto significa que este elemento influencia os elementos pointcuts. Vale salientar que o source é o elemento pai daqueles declarados nos advices. No modo textual temos 2 blocos de pointcuts, identificados por “PC1” e “PC2” (linhas 3 a 5). A primitiva “include” (linhas 3, 4 e 5), indica que os advices serão incluídos nos elementos que representam os pointcuts. Ainda existe a primitiva “substitute”, que indica que os advices substituem os elementos que representam os pointcuts. O operador and (linha 4) serve para agregar elementos pointcuts, portanto só deve ser utilizado quando houver mais de um elemento pointcut. Ainda existem os operadores dos tipos or e not. Para cada bloco de pointcuts temos um bloco de advices (linhas 6 a 11). Nestes blocos são declarados os elementos que estão espalhados nos elementos pointcuts.
Figura 6. Relacionamento transversal em PL-AOVgraph (a) Modo gráfico; (b) Modo textual
Resumindo, este relacionamento transversal indica que o elemento “Persistence in [BD]” (linha 7) é uma decomposição do elemento “Manage [project]” (linha 3). Enquanto o elemento “Persistence in [file]” (linha 10) é uma decomposição tanto do elemento “Install [application]” (linha 4) quanto do elemento “Uninstall [application]” (linha 5). Em outras palavras, para atingir o requisito “Manage [project]” é necessário satisfazer ao requisito “Persistence in [BD]”. Da mesma forma, para alcançar os requisitos “Install [application]” e “Uninstall [application]” é necessário prover o requisito “Persistence in [file]”.
AOV-Graph permite a inclusão de novas propriedades ao modelo de metas através da palavra reservada property. Para oferecer suporte a variabilidade, PL-AOVgraph inclui seis propriedades descritas a seguir.
As propriedades cardinalityMin e cardinalityMax possibilitam a atribuição de cardinalidade, mínima e máxima respectivamente, aos elementos, oferecendo maior flexibilidade à linguagem, não se limitando apenas as contribuições pré-definidas.
A contribuição xor em AOV-Graph dá a idéia de agrupamento, porém não permite definir os limites do grupo, ou seja, não torna explícito quais dos elementos que possuem este relacionamento fazem parte do mesmo grupo, assumindo que todos pertencem mesmo agrupamento. Este pode não ser o resultado esperado, por este motivo PL-AOVgraph inclui a propriedade groupFeature que permite a declaração explícita dos membros de um grupo. Esta propriedade atua em conjunto com as propriedades cardinalityGroupMin e cardinalityGroupMax, que possibilitam a inserção de cardinalidade, mínima e máxima respectivamente, aos grupos.
A propriedade isFeature é relevante quando se deseja obter um Modelo de Features a partir de uma especificação PL-AOVgraph, uma vez que nem sempre um requisito é equivalente a uma feature. Isto vai depender do nível de abstração do Modelo de Features. Assim, quando o analista perceber que um determinado requisito não corresponde a uma feature, este irá configurar a propriedade isFeature como “no”.
A Figura 7 ilustra a utilização destas propriedades em parte da especificação PL-AOVgraph do sistema ECommerce. A cardinalidade da task “Method” é atribuída diretamente através das propriedades cardinalityMin e cardinalityMax (linha 6), indicando que esta deve ocorrer no mínimo uma e no máximo n vezes, para que a task “CustomMethods” seja satisfeita. É importante observar que neste caso o relacionamento inc-or não se adequa, pois este só pode ser utilizado em agrupamentos.
cardinalityGroupMin especifica a cardinalidade mínima do grupo como 2; e cardinalityGroupMax especifica a cardinalidade máxima do grupo como 4.
A task “CustomMethods” (linha 4) possui a propriedade isFeature configurada como “no”. Isto significa que se esta especificação for mapeada para Modelo de Features, nem “CustomMethods” nem seus filhos (neste caso “Method”) serão mapeados para features. A decisão de impedir que estas tasks se tornem features parte do analista ao elaborar a especificação PL-AOVgraph, se este decidir que no Modelo de Features não há necessidade de atingir nesse nível de detalhamento.
Figura 7. Propriedades de PL-AOVgraph para suporte a cardinalidade
2.3. MDD (Model-Driven Development)
O desenvolvimento orientado a modelos (MDD) (Stahl et al, 2006) visa aumentar o nível de abstração em que o desenvolvedor atua, enfatizando a função dos modelos como elementos fundadores da implementação. Um modelo é a conceitualização do sistema representando uma visão completa do mesmo, ou parte dele, através de visões particulares.
Dessa forma, os diagramas conceituais não são elaborados apenas para modelar o sistema de forma abstrata, mas também para serem utilizados como entrada para ferramentas de geração de código, com o intuito de refinar gradualmente o sistema. Com isso as modificações realizadas nos modelos se propagam automaticamente para o código, facilitando a manutenção e o processo de evolução do software.
No MDD cada modelo precisa estar em conformidade com seu metamodelo, ou seja, deve estar escrito na linguagem do metamodelo (Medeiros, 2008). O metamodelo representa a sintaxe abstrata da linguagem e descreve todos os conceitos que podem ser utilizados nessa linguagem. Em geral, podemos ver o metamodelo como um modelo que descreve outro modelo. Por sua vez, o metamodelo deve estar em conformidade com o seu metametamodelo. Entre os metametamodelos existentes podemos citar o MOF (OMG/MOF, 2005), definido como um padrão da OMG, o Ecore (Budinsky et al, 2004), introduzido com o Eclipse Modelling Framework - EMF (Budinsky et al, 2004) e o KM3 (Jouault et al, 2003).
Os principais elementos necessários para automatizar as transformações MDD são apresentados na Figura 8. Para realizar a criação dos modelos é necessária uma ferramenta de modelagem, que deve garantir que os modelos produzidos estejam em conformidade com um determinado metamodelo. Estes modelos serão entrada para as transformações que irão gerar outros modelos ou o próprio código. Também é necessária uma ferramenta que permita a construção de regras de mapeamento, que implementam as transformações. Com as regras de mapeamento implementadas e os modelos de entrada definidos, um mecanismo irá executar as transformações, produzindo outros modelos ou artefatos de software.
Figura 8. Principais elementos do MDD
Fonte: (Lucrédio, 2009)
benefícios do que a reutilização do código-fonte; (v) Corretude: evita a ocorrência de erros acidentais, como erros de digitação, além de permitir a identificação de erros conceituais em um nível mais alto de abstração.
2.4. ATL (Atlas Transformation Language)
ATL (Bézivin et al, 2003) é uma linguagem para a realização de transformações entre modelos no contexto do MDD, que possui uma sintaxe textual concreta, permitindo a produção de modelos a partir de um modelo de entrada (Medeiros, 2008), desde que todos os modelos envolvidos na transformação estejam de acordo com seu próprio metamodelo. A Figura 9 ajuda a compreender como funciona o processo de transformação, ilustrando o mapeamento de Author para Person.
Figura 9. Processo de transformação de Author para Person
Fonte: (Atlas, 2003)
O modelo authors.ecore, que é a entrada para a transformação, deve estar em conformidade com o metamodelo Authors.ecore. As regras de mapeamento são definidas em Author2Person.atl, que deve estar em conformidade com o metamodelo ATL. A transformação produz o modelo persons.ecore, que obedece a sintaxe do metamodelo Person.ecore. Neste exemplo todos os metamodelos estão em conformidade com o metametamodelo Ecore.
As transformações ATL consistem em regras de mapeamento que definem como os elementos do modelo de entrada são compostos e percorridos, para criar os elementos que irão compor o modelo de saída (Medeiros, 2008). Estas transformações são definidas através de módulos ATL.
De acordo com Simão (2010), um módulo ATL é composto por: (i) Header Section: define o nome do módulo e das variáveis que irão representar os modelos de origem e destino; (ii) Import Section: permite importar bibliotecas ATL, caso necessário; (iii) Helper: equivalente aos métodos em Java; (iv) Rule: pode ser dos tipos (a) matched rule, núcleo da transformação declarativa; (b) lazy rule, semelhante à anterior, mas aplicada apenas quando chamada por outras regras; (c) called rule, núcleo da transformação imperativa.
A Figura 10 apresenta o código em ATL da transformação de Author para Person, que corresponde a Authors2Person.atl na Figura 9. Devido sua simplicidade, neste exemplo encontramos apenas a seção Header (linhas 1 e 2) e a seção Rule (linhas 4 a 12).
Figura 10. Transformação ATL de Author para Person
3.
Mapeamento entre PL-AOVgraph e Modelo de Features
O mapeamento proposto por Santos (2010) permite obter uma especificação PL-AOVgraph a partir de um Modelo de Features, e vice-versa, porém, este mapeamento possui algumas restrições. Santos (2010) relata que devido a simplicidade semântica do Modelo de Features, alguns elementos de PL-AOVgraph não podem ser representados neste modelo, como os tipos dos elementos (task, goal e softgoal), advices dos tipos before e after, intertype declarations, pointcuts com primitiva substitute e operador or. Estas limitações podem ocasionar inconsistências nos modelos produzidos pelo mapeamento. Por este motivo, elaboramos regras de mapeamento complementares com o objetivo de solucionar estas restrições, tornando o mapeamento mais consistente.
A seção 3.1 especifica o processo, ou seja, o fluxo seguido pelos artefatos no processo de mapeamento; a seção 3.2 apresenta as regras de mapeamento entre PL-AOVgraph e Modelo de Features definidas por Santos (2010), e as restrições deste mapeamento; a seção 3.3 define as regras de mapeamento complementares.
3.1. Processo
A Figura 11 mostra como o mapeamento entre PL-AOVgraph e Modelo de Features pode ser utilizado no processo de desenvolvimento de LPS’s. Duas situações podem ocorrer: (i) apenas a especificação PL-AOVgraph está disponível (ilustrada acima da linha pontilhada), e (ii) apenas o Modelo de Features está disponível (ilustrada abaixo da linha pontilhada). No primeiro caso, a partir dos requisitos é feita a modelagem da especificação PL-AOVgraph, que será a entrada do mapeamento para Modelo de Features. No segundo caso, com base nos requisitos o Modelo de Features é desenvolvido e será a entrada do mapeamento para PL-AOVgraph.
Figura 11. Processo de mapeamento entre PL-AOVgraph e Modelo de Features
Em seguida, em ambos os casos, o modelo produzido deve ser analisado, a fim de identificar possíveis erros e omissões. Se houver necessidade de mudanças o modelo passará por ajustes manuais. Por exemplo, como o Modelo de Features e PL-AOVgraph possuem diferentes níveis de abstração e as transformações produzem modelos de saída com o mesmo nível de abstração do modelo de entrada, se na etapa de análise for constatado que o modelo de saída é muito abstrato ou muito detalhado, o engenheiro de requisitos terá que adaptá-lo manualmente. O fato é que, o modelo gerado servirá, no mínimo, como versão inicial, seja do Modelo de Features ou da especificação PL-AOVgraph. Depois dos ajustes, ou no caso destes não serem necessários, temos a especificação PL-AOVgraph e o Modelo de Features da LPS, terminando nosso processo.
Ainda é possível utilizar o Modelo de Features e a especificação PL-AOVgraph do nosso processo, como entrada para outros processos (representado pelo bloco pontilhado na Figura 11). Por exemplo, Coelho (2012) propõe um mapeamento bi-direcional entre PL-AOVgraph e a linguagem de descrição arquitetural PL-AspectualACME (Batista et al, 2009), conforme o processo apresentado na Figura 12. Dessa forma, a especificação PL-AOVgraph obtida no nosso processo pode ser a entrada para esta transformação, produzindo a especificação da arquitetura da LPS. Assim, saímos do nível de requisitos para o nível da arquitetura, partindo do Modelo de Features, passando por AOVgraph até PL-AspectualACME, mantendo a consistências entre estes modelos.
Figura 12. Processo de mapeamento entre PL-AOVgraph e PL-AspectualACME
Fonte: (Coelho, 2012)
3.2. Mapeamento entre PL-AOVgraph e Modelo de Features
Tabela 1. Elementos de PL-AOVgraph X elementos do Modelo de Features
3.2.1. Mapeamento de PL-AOVgraph para Modelo de Features
Conforme podemos observar na Tabela 2, o mapeamento de PL-AOVgraph para Modelo de Features é realizado através de 9 regras que exemplificaremos a seguir, através dos sistemas Smart Home, por ser o sistema utilizado em nosso estudo de caso, e ECommerce, para a demonstração de regras não usadas no estudo de caso do Smart Home.
Tabela 2. Regras de transformação de PL-AOVgraph para Modelo de Features
Fonte: (Santos, 2010)
Figura 13. Especificação PL-AOVgraph parcial de Smart Home
Fonte: Adaptado de Santos (2010)
Figura 14. Modelo de Features obtido a partir da especificação PL-AOVgraph da Figura 13
1. goal_model “Smart Home” { 2. task “Fire Detection” (or) {
3. task “Activate Alarm” (and) {
4. task “Activate Alarm [Visual]” (inc-or) { property { isFeature = no } } 5. task “Activate Alarm [Sound]” (inc-or) { property { isFeature = no } }
6. }
7. task "Indicate Emergency Exits" (and) {} 8. task “Sprinkle Water” (and) {}
9. }
10. task “Light Management” (and) {
11. task “Regulate Intensity Light” (inc-or) {} 12. task “Select Predefined Values [Light]” (inc-or) {
13. task “Select mode [TV watching]” (inc-or) {}
14. task “Select mode [Reading]” (inc-or) {}
15. task “Select mode [Normal]” (inc-or) {}
16. task “Select mode [Ambient]” (inc-or) {}
17. }
18. }
19. task “Presence Simulation” (or) {
20. task_ref “Regulate Blinds” (inc-or) {}
21. }
22. task “Minimize Waste of Energy” (or) { 23. task “Measure Luminosity” (and) {} 24. task “Detect Movement” (and) {} 25. task "Turn Off" (and) {
26. task_ref “Regulate Thermostat” (inc-or) {}
27. }
28. }
29. softgoal "Low Response Time" (and) {..} 30. softgoal “Availability” (and) {
31. softgoal “Availability [Sensors]” (and) {…} 32. softgoal “Availability [Actuators]” (and) {…}
33. }
34. correlation (help) {
35. source: softgoal_ref “Low Response Time” 36. target: softgoal_ref “Availability”
37. }
38. crosscutting {
39. source: taks_ref “Light Management”
40. pointcut PC1: include “Presence Simulation” and include “Turn Off”
41. advice (around): PC1{
42. task_ref “Regulate Intensity Light” (inc-or) 43. }
As regras utilizadas nesta transformação foram aplicadas da seguinte forma:
• Regra 1: O goal model “Smart Home” (linha 1 da Figura 13) da especificação PL-AOVgraph, equivale a raiz do Modelo de Features.
• Regra 2: A hierarquia do Modelo de Features gerado é a mesma da especificação PL-AOVgraph apresentada na Figura 13.
• Regra 3: Os elementos com relacionamentos de contribuição and (por exemplo, “Activate Alarm”, linha 3), or (por exemplo, “Fire Detection”, linha 2) e inc-or (por exemplo, “Regulate Intensity Light”, linha 11), tornaram-se features obrigatórias, opcionais e inclusive-or, respectivamente.
• Regra 6: As referências (por exemplo, “Regulate Blinds”, linha 20”) foram mapeadas para features de referência no Modelo de Features.
• Regra 7: As informações do relacionamento de correlação (linhas 34 a 37) foram armazenadas em uma anotação no Modelo de Features. De forma que a feature “Low Response Time”, por ser o source do relacionamento, recebeu a anotação, cuja descrição consiste no tipo da correlação (help) juntamente com o target do relacionamento (Availability).
• Regra 8: O relacionamento transversal não possui uma representação específica no Modelo de Features. Sendo assim, o advice “Regulate Intensity Light” (linha 42) gera duas features de referência, que são chamadas pelas features correspondentes aos pointcuts “Presence Simulation” e “Turn Off” (linha 40).
• Regra 9: Na transformação de Modelo de Features para PL-AOVgraph todas as features são mapeadas para tasks, porém na transformação inversa os elementos que possuírem a propriedade isFeature declarada como “no” não aparecerão no Modelo de Features, ou seja, só se tornam features os elementos que não possuírem esta propriedade ou se esta estiver declarada como “yes”. Por este motivo as tasks “Activate Alarm [Visual]” (linha 4) e “Activate Alarm [Sound]” (linha 5), não se tornaram features. Vale salientar que se essas tasks possuíssem filhos, estes também não se tornariam features. Também é importante deixar claro que a decisão do que é ou não uma feature, não faz parte do processo de transformação, mas é uma decisão tomada pelo engenheiro de requisitos ao elaborar a especificação PL-AOVgraph.
Para demonstrá-las podemos observar um trecho da especificação PL-AOVgraph de ECommerce, apresentada na Figura 15. Aplicando as regras de mapeamento 4 e 5 neste exemplo obteremos o Modelo de Features da Figura 16.
Figura 15. Trecho da especificação PL-AOVgraph de ECommerce
Figura 16. Modelo de Features obtido a partir da especificação PL-AOVgraph da Figura 15
Conforme a regra 4, a task “Method” (linha 5 da Figura 15), que possui a propriedade cardinalityMin definida como 1 e cardinalityMax definida como n, torna-se uma feature com a cardinalidade especificada nestas propriedades.
3.2.2. Mapeamento de Modelo de Features para PL-AOVgraph
Nesta sub-seção exemplificamos o uso das regras de transformação apresentadas na Tabela 3.
Tabela 3. Regras de transformação de Modelo de Features para PL-AOVgraph
Fonte: (Santos, 2010)
Aplicando as regras de mapeamento da Tabela 3, o Modelo de Features parcial de Smart Home (Figura 17) resultará na especificação PL-AOVgraph apresentada na Figura 18.
Figura 17. Modelo de Features parcial de Smart Home
Figura 18. Especificação PL-AOVgraph obtida a partir do Modelo de Features da Figura 17
Nesta transformação foram utilizadas as seguintes regras:
• Regra 1: A raiz do Modelo de Features, denominada “Smart Home”, equivale ao goal model na especificação PL-AOVgraph (linha 1 da Figura 18).
• Regra 2: A especificação PL-AOVgraph da Figura 18 obedece à mesma hierarquia do Modelo de Features apresentado na Figura 17.
• Regra 3: Features obrigatórias (por exemplo, “BlindActuador”) e opcionais (por exemplo, “FloorGUI”), tornam-se tasks com relacionamentos de contribuição dos tipos and (linha 19) e or (linha 3), respectivamente.
1. goal_model “Smart Home” {
2. task “Floor(int)” (and) { property{ cardinalityMin = 1; cardinalityMax = n; }
3. task “FloorGUI” (or) {
4. task_ref “GUI” (and) {}
5. }
6. task “Door” (or) { property { cardinalityMin = 0; cardinalityMax = n; }
7. task “DoorSensor” (or) {}
8. task “DoorOpener” (or) {}
9. }
10. task “Room(String)” (and) { property { cardinalityMin = 1; cardinalityMax = n; } 11. task “RoomDevice” (or) { property { cardinalityMin = 0; cardinalityMax = n; } } 12. task “WaterSprinkler” (or) { property { cardinalityMin = 0; cardinalityMax = n; } }
13. task “RoomGUI” (or) {
14. task_ref “GUI” (and) {}
15. }
16. task “Alarm” (or) {}
17. task “Window” (or) { property { cardinalityMin = 0; cardinalityMax = n; }
18. task “Blind” (or) {
19. task “BlindActuador” (and) {}
20. }
21. task “WindowActuator” (or) {}
22. task “WindowSensor” (or) {}
23. }
24. task “Light” (or) { property { cardinalityMin = 0; cardinalityMax = n; }
25. task “Dimmer” (or) { property { cardinalityMin = 0; cardinalityMax = n; } } 26. task “LightSwitch” (or) { property { cardinalityMin = 0; cardinalityMax = n; } }
27. }
28. task “ExternalDoor” (or) { property { cardinalityMin = 0; cardinalityMax = n; } } 29. task “FireSensor” (or) { property { cardinalityMin = 0; cardinalityMax = n; } }
30. task “Heater” (or) {
31. task “Thermostat” (and) {
32. task_ref “MeasurementUnits” (and) {}
33. }
34. }
35. task_ref “BasicFacilities” (or) {}
36. task_ref “ComplexFacilities” (or) {}
37. }
38. }
39. task “Staircase” (or) { property { cardinalityMin = 0; cardinalityMax = n; } 40. task “upperRoom(String)” (and) {}
41. task “lowerRoom(String)” (and) {}
42. }
43. task “CentralGUI” (and) {
44. task_ref “GUI” (and) {}
45. }
• Regra 4: Features com cardinalidade (por exemplo, “Floor”), são mapeadas para tasks com as propriedades cardinalityMin e cardinalityMax (linha 2).
• Regra 6: Features de referência (por exemplo, “GUI”) se tornam task_refs em PL-AOVgraph (linha 4).
A regra 5 não foi aplicada, pois o Modelo de Features não possui agrupamentos, mas funciona de forma semelhante à regra 4.
A regra 7 também não foi utilizada, pois o Modelo de Features da Figura 17 não possui anotação. Entretanto, se considerarmos o Modelo de Features apresentado na Figura 14, veremos que a feature “Low Response Time” possui uma anotação. Dessa forma, conforme a regra 7, seria gerado um relacionamento de correlação, conforme o apresentado na Figura 19 (linhas 1 a 4). Como “Low Response Time” é a feature que possui a anotação, se torna o elemento source do relacionamento (linha 2). De acordo com a Figura 14, a anotação possui o seguinte conteúdo: “help: Availability”. Logo, o tipo da correlação é definido como “help” (linha 1) e o target como “Availability” (linha 3).
Figura 19. Trecho da especificação PL-AOVgraph obtida a partir do Modelo de Features da Figura 14
Conforme a regra 8 da Tabela 3, as features “GUI”, “BasicFacilities” e “ComplexFacilities”, do Modelo de Features apresentado na Figura 17, poderiam ser consideradas advices de um relacionamento transversal, por serem referências que aparecem mais de uma vez no Modelo de Features. Porém, no Modelo de Features completo de Smart Home, definido por Sánchez (2007), podemos observar que cada uma destas features são Modelos de Features separados. Portanto, estas features merecem um tratamento especial, que ficará a cargo do engenheiro de requisitos. Assim, nesse caso a regra 8 não foi aplicada.
Porém, se considerarmos o Modelo de Features da Figura 14, veremos que a feature de referência “Regulate Intensity Light” aparece duas vezes no modelo, portanto representa o advice do relacionamento transversal (linha 9 da Figura 19). Enquanto “Presence Simulation” e “Turn Off” são os pointcuts (linha 7 da Figura 19), pois são as features que chamam a feature correspondente ao advice. O source do relacionamento transversal é “Light
…
1. correlation (help) {
2. source: softgoal_ref “Low Response Time” 3. target: softgoal_ref “Availability”
4. }
5 crosscutting {
6. source: task_ref “Light Management”
7. pointcut PC1: include “Presence Simulation” and include “Turn Off”
8. advice (around): PC1 {
9. task_ref “Regulate Intensity Light” (inc-or)
10. }
11. }
Management” (linha 6 da Figura 19), por ser pai da feature referenciada (Regulate Intensity Light).
3.2.3. Restrições do Mapeamento
As seguintes restrições afetam a consistência dos modelos produzidos pelo mapeamento proposto por Santos (2010):
1. No Modelo de Features não existe a classificação de requisitos como funcional, não funcional ou objetivo organizacional. Tudo é tratado simplesmente como feature. Por esse motivo, todas as features são transformadas em um único tipo de requisito, task. Dessa forma, geram-se erros nos casos em que a feature representa um requisito não funcional (goal) ou um objetivo organizacional (softgoal).
2. O Modelo de Features não oferece suporte a orientação a aspectos, ou seja, não permite a representação de relacionamentos transversais de forma explícita como em PL-AOVgraph. Assim, não foi possível identificar neste modelo elementos correspondentes aos advices dos tipos before e after, considerando que todos são around. Também não foi possível a identificação de elementos correspondentes as intertype declarations. Quanto aos pointcuts, não foi encontrada nenhuma forma de utilização da primitiva substitute, considerando apenas a primitiva include. O mesmo acontece com os operadores, onde apenas and é considerado.
3. O Modelo de Features gerado a partir de uma especificação PL-AOVgraph usualmente possui um grande número de features, uma vez que cada requisito (task, goal, softgoal) é mapeado para uma feature. Isto pode ser visto como vantagem, pois torna o modelo mais completo, contudo pode torná-lo muito extenso, o que dificulta sua visualização e análise da variabilidade. A propriedade isFeature tem o objetivo de contornar este problema. Porém, se um elemento possuir esta propriedade, ele e todos os seus filhos não se tornarão features, o que nem sempre é desejável. É possível que se pretenda eliminar apenas um determinado elemento, atribuindo os filhos do elemento eliminado ao seu pai. Além disso, é possível que uma feature represente não apenas um, mas sim um conjunto de requisitos.
nome de uma feature é formado por uma ou duas palavras, que geralmente são substantivos. Dessa forma, os modelos gerados, sejam especificações PL-AOVgraph ou Modelos de Features, podem não ser nomeados de forma adequada, necessitando de ajustes nesse sentido.
3.3. Regras Complementares
As Tabelas 4 e 5 apresentam as regras de mapeamento de PL-AOVgraph para Modelo de Features e de Modelo de Features para PL-AOVgraph, respectivamente, que permitem solucionar as restrições 1 e 2, descritas na seção 3.2.3. As regras foram enumeradas dando continuidade à numeração das regras apresentadas nas Tabelas 2 e 3, respectivamente.
Regra Descrição
10 O tipo de cada elemento PL-AOVgraph é indicado no conteúdo de uma anotação, que é adicionada a cada
feature.
11
Intertype declarations do tipo element se tornam features, que são adicionadas à feature correspondente ao source do relacionamento transversal. Estas features ainda possuem uma anotação indicando que esta foi originada a partir de um intertype declaration do tipo element, seguido do tipo do elemento PL-AOVgraph (task, goal, softgoal), por exemplo: Intertype Declaration (element: task).
12
Intertype declarations do tipo attribute se tornam features, que são adicionadas à feature correspondente ao source do relacionamento transversal. Estas features não possuem cardinalidade nem a anotação que indica o tipo do elemento PL-AOVgraph. O valor do intertype declaration attribute será o nome da feature e o atributo será indicado no conteúdo de uma anotação com o seguinte formato: Intertype Declaration (attribute: Nome_do_Atributo).
13 Se um pointcut possui um operando com a primitiva substitute, a feature correspondente ao operando recebe
uma anotação indicando a primitiva e as features que poderão a substituir.
14
Advices before ou after são mapeados para features de referência, conforme a quantidade de operandos include do pointcut afetado pelo advice, ou para anotações, conforme a quantidade de operandos substitute do pointcut afetado pelo advice. No primeiro caso, as features de referência são adicionadas as features pais das correspondentes aos operandos include e possuem uma anotação indicando o tipo do advice, ex: advice: after. No segundo caso, as anotações, que indicam as features que podem substituir e o tipo do advice, são adicionadas as features pais das correspondentes aos operandos substitute.
Tabela 4. Regras complementares para o mapeamento de PL-AOVgraph para Modelo de Features
Regra Descrição
9 Se uma feature possuir anotação e no conteúdo da anotação houver o tipo do elemento PL-AOVgraph (task,
goal, softgoal), será gerado um elemento conforme o especificado na anotação.
10 Se uma feature possui uma anotação que contém as palavras “Intertype Declaration” e “element”, será mapeada
para um intertype declaration do tipo element.
11
Se uma feature possui uma anotação que contém as palavras “Intertype Declaration” e “attribute”, será mapeada para um intertype declaration do tipo attribute, cujo valor corresponde ao nome da feature e o atributo consta no conteúdo da anotação.
12 Se uma feature possuir uma anotação que contenha a palavra “substitute” será mapeada para um operando com
primitiva substitute.
13
Se uma feature de referência possuir uma anotação que contenha a palavra “advice” seguida por “before” ou “after”, esta será mapeada para um advice conforme o tipo indicado na anotação e os pointcuts serão seus irmãos. Se uma feature possui uma anotação que contenha as palavras “substitute” e “advice” seguida por “before” ou “after”, a feature declarada na anotação será mapeada para um advice conforme o tipo indicado na anotação e os pointcuts serão seus filhos.
14 Se for identificado um pointcut que possua mais de um operando e que é afetado por um advice before ou after,
será utilizado o operador or entre seus operandos.
As regras 9 (Tabela 4) e 10 (Tabela 5) foram apresentadas em Santos (2011b) com o objetivo de eliminar a restrição 1 do mapeamento proposto por Santos (2010).
Na Figura 20 podemos observar um trecho da especificação PL-AOVgraph de Smart Home, que é transformado em um Modelo de Features, que por sua vez é transformado novamente em PL-AOVgraph. Comparando as especificações podemos ver que ambas são idênticas. Isso só é possível porque cada feature recebeu uma anotação indicando se corresponde a uma task, goal ou softgoal. Assim, ao realizar o mapeamento de Modelo de Features para PL-AOvgraph a anotação é verificada, gerando um elemento conforme o tipo indicado na anotação, em vez de gerar apenas tasks por default.
Figura 20. Mapeamento entre tipos de elementos PL-AOVgraph e anotações no Modelo de Features
As demais regras das Tabelas 4 e 5 propõem-se a solucionar a restrição 2 do mapeamento apresentado por Santos (2010).
A Figura 21 demonstra a utilização das regras 11 (Tabela 4) e 10 (Tabela 5). Vale salientar que tanto a especificação PL-AOVgraph quanto o Modelo de Features apresentados nesta figura, contém apenas os elementos necessários para a exemplificação das regras, sendo, portanto, uma versão parcial do original. Um dos elementos omitidos no Modelo de Features foram as anotações referentes ao tipo do elemento PL-AOVgraph, deixando apenas as que realmente eram relevantes para a demonstração.
