Processo de Desenvolvimento de Variabilidade

O processo de desenvolvimento de variabilidade contém as recomendações e as etapas para criar uma DSPL seguindo o modelo de referência ISALYNE-RM (Figura 5.2). É impor- tante enfatizar que esse processo tem como foco a construção do subsistema gerenciado, ou seja, definindo como a DSPL deve ser projetada e desenvolvida para atender as regras do ISALYNE-RM, de modo a permitir ser gerenciada pelo Reconfigurador durante a sua execução. Afinal, ambas as partes do sistema autoadaptativo, os subsistemas gestor (Re- configurador) e gerenciado (DSPL), devem estar em conformidade entre si, para permitir a reflexão. Esse processo de desenvolvimento é organizado em cinco etapas, seguindo a notação BPMN16 _{[137], como mostra a Figura 5.8.}

Figura 5.8: Processo de desenvolvimento de variabilidade.

Etapa 1 – Análise de Domínio. O engenheiro de software realiza a análise de domínio da DSPL, definindo os requisitos e as metas de variabilidade. Essa etapa é subdividida em dois passos:

1.A. Análise dos Requisitos – O engenheiro de software planeja a DSPL e realiza o levantamento dos requisitos de domínio, produzindo um conjunto de artefatos. Esses artefatos são produzidos de acordo com as necessidades dos especialistas de domínio, stakeholders e engenheiros de software, não havendo recomendações específicas que guiem a elaboração desses artefatos dentro do modelo de referência ISALYNE-RM.

1.B. Modelagem de Features – Em seguida, o engenheiro de software define as varia- bilidades que fazem parte da DSPL, elaborando o modelo de features que deve conter as features e os seus respectivos pontos de variação. A estratégia de modelagem de features a ser utilizada foi definida no requisito RV.2, podendo conter features estáticas e dinâmi- cas. As variabilidades podem ser representadas por composições contendo uma ou mais

features aplicadas à operadores lógicos como OR, ALT (alternativo) e opcional, de acordo com a notação estabelecida no requisito RV.2.

Etapa 2 – Projeto da DSPL. Nesta etapa, o engenheiro de software projeta a arqui- tetura da linha de produtos, também chamada de modelo PLA. Para a especificação da PLA, o ISALYNE-RM recomenda a adoção do método FArM (Feature-Architecture Map- ping) [171] para gerar um mapeamento entre o modelo features e o modelo PLA. Como apresentado na Seção 2.3.5, o método FArM realiza uma sequência de transformações no modelo de features para mapear features a elementos arquiteturais, gerando o modelo PLA [171]. Entretanto, o engenheiro de software pode projetar o modelo PLA utilizando outro método equivalente ou até sem o apoio de um método. Todavia, a adoção de um método específico como FArM oferece garantias de corretude ao mapeamento entre o mo- delo de features e o modelo PLA. É importante destacar que a apropriada especificação do modelo PLA e da rastreabilidade entre features e elementos arquiteturais é essencial para a correta derivação de produtos [171]. Assim, o engenheiro de software realiza o projeto arquitetural da PLA em duas perspectivas complementares:

2.A. Modelagem Arquitetural – Primeiramente, o engenheiro de software usa o método FArM ou equivalente para obter a PLA e a representa na forma de modelo arquitetural da PLA, seguindo o requisito RV.3.

2.B. Rastreabilidade entre features e elementos arquiteturais – Em seguida, o enge- nheiro de software define o mapeamento entre features (do modelo de features) e os elementos arquiteturais (do modelo PLA) que as implementam. As transformações do método FArM também têm como resultado esse mapeamento (Seção 2.3.5). Para cada feature não abstrata contida no modelo de features, deve ser associado um ou mais elemen- tos arquiteturais. A representação da rastreabilidade pode ser feita de diferentes formas e deve seguir o requisito RV.6. A Figura 5.9 ilustra um mapeamento entre features e elementos arquiteturais.

Figura 5.9: Mapeamento entre modelo de features e elementos arquiteturais.

Etapa 3 – Implementação. Após as fases de análise e projeto, o engenheiro de soft- ware constrói a DSPL em dois passos:

3.A. Codificação da DSPL– Nessa etapa, o engenheiro de software e os desenvolvedores implementam a DSPL com seus métodos de negócio, seguindo: (i) os requisitos e o modelo de features definidos na etapa 1; e (ii) o modelo PLA projetado na etapa 2.

3.B. Codificação dos sensores e efetores – A implementação de sensores e efetores deve seguir as especificações e recomendações do Módulo de Interface Reflexiva (Seção 5.5), que define as interfaces entre o Reconfigurador e a DSPL.

Etapa 4 – Derivação. Após a codificação da DSPL, o engenheiro de software realiza a derivação da DSPL em três passos:

4.A. Configuração do Produto (opcional) – O engenheiro de software define uma con- figuração de produto dinâmico a partir do modelo de features. Uma configuração de produto dinâmico, ou simplesmente produto dinâmico, é uma configuração válida do mo- delo de features que contém as composições dinâmicas. Esse passo é opcional, uma vez que a configuração de um produto dinâmico somente ocorre se a DSPL também lida com variabilidade estática, realizando o binding time de projeto. Caso contrário, quando a DSPL somente lida com variabilidade dinâmica, então não há decisões a serem tomadas nesse momento. Para criar um produto dinâmico, o engenheiro de software realiza a to- mada de decisão para todas as composições estáticas, ou seja, todos os pontos de variação com binding time de projeto devem ser resolvidos. Entretanto, o engenheiro de software deve postergar as decisões relacionadas às composições dinâmicas para serem resolvidas pelo Reconfigurador durante a execução. Assim, um produto dinâmico é um subconjunto do modelo de features que inclui um conjunto de features estáticas obrigatórias e um con- junto de features dinâmicas pertencentes a composições dinâmicas. Um produto dinâmico é uma DSPL sem composições estáticas.

4.B. Geração dos Artefatos da Base de Conhecimento – O engenheiro de software prepara os artefatos requeridos para a adaptação durante a execução. Esses artefatos são representações dos modelos elaborados até então, porém traduzidos a uma linguagem para que possam ser lidos pelo Reconfigurador. O ISALYNE-RM recomenda o uso de uma linguagem textual para traduzir esses artefatos da base de conhecimento, pois estes necessitam ser lidos e manipulados durante a execução. Eichelberger e Schmid [72] fizeram uma revisão sistemática da literatura, onde analisaram diversas linguagens textuais para modelagem de features, como FDL [179], VSL [3], FAMILIAR [5], Clafer [25], TVL [53] e VELVET [163]. Como alternativa, também pode ser usada a linguagem XML, uma vez que muitas ferramentas de modelagem de features e de modelagem arquitetural podem exportar seus modelos para o formato XML. Comumente, documentos XML podem ser facilmente traduzidos e transformados de um XML para outro, sendo facilmente proces- sados durante a execução. Assim, os artefatos que fazem parte dos artefatos da base de conhecimento são:

• Arquivo do modelo de features: esse arquivo representa a variabilidade dinâmica da DSPL e define, em relação a features, quais configurações o Reconfigurador pode aplicar à DSPL em tempo de execução. O arquivo do modelo de features é (i) equivalente ao modelo de features da DSPL, definido na etapa 1, caso a DSPL lide apenas com variabilidade dinâmica; ou (ii) um subconjunto do modelo de features, que corresponde ao produto dinâmico, conforme definido na etapa 4.A;

• Arquivo da PLA: este arquivo representa o modelo PLA e contém informações sobre os: (i) elementos arquiteturais estáticos e dinâmicos; e (ii) sensores anexados aos

elementos arquiteturais dinâmicos que precisem ser monitorados; e

• Arquivo de rastreabilidade (opcional): este arquivo contém o mapeamento entre as features e os elementos arquiteturais, definido no passo 2.B. Tal arquivo é opcional, uma vez que a rastreabilidade pode ter sido estabelecida de forma entrelaçada, junto ao modelo de features ou ao modelo arquitetural, conforme definido no requisito RV.6.

4.C. Compilação do Produto Dinâmico – Finalmente, o engenheiro de software com- pila o sistema que será executado. O sistema compreende o Reconfigurador, a DSPL, juntamente com seus sensores e efetores.

Etapa 5 – Teste. Após o término da implementação, o engenheiro de software rea- liza testes de unidade e de integração na DSPL desenvolvida, de acordo com critérios previamente definidos. A atividade de teste não pertence ao escopo deste trabalho. Infor- mações adicionais sobre testes de software para SPLs podem ser encontradas na revisão sistemática da literatura realizada por Razak et al. [158].

Etapa 6 – Implantação. Finalmente, a DSPL deve ser implantada no ambiente de execução. É importante destacar que a DSPL, o Reconfigurador e a interface reflexiva entres eles (sensores e efetores), compreendem um único sistema e, portanto, devem ser implantados conjuntamente.