Dimensão de Variabilidade em DSPL

D2-A1. Tipo de Variabilidade. Esta questão de projeto estabelece o tipo de va- riabilidade da DSPL. A variabilidade estática é executada pelo compilador, enquanto a variabilidade dinâmica é executada pelo sistema em execução. Algumas soluções de DSPL lidam apenas com a variabilidade dinâmica, enquanto outras executam a variabilidade es- tática e dinâmica. Sendo assim, a classificação é realizada levando-se em consideração os

Dimensão de Variabilidade em DSPL Tipo de Variabilidade Modelo Conceitual de Variabilidade Modelo Arquitetural Estilo Arquitetural Elemento da Variabilidade Rastreabilidade da Variabilidade Plataforma Dinâmica Estática + Dinâmica Modelo de features Modelo de decisões Cenários de mudanças Perfis Regras/Condições Rótulos de variantes/Anotações Linguagens personalizadas ADL Baseado em componentes Orientado a serviços Híbrido Código Componente Serviço Aspecto Arquitetura Ligação direta Matriz de rastreabilidade Regras de transformação Modelo de componentes Modelo de serviços Framework ou API Ferramenta Estratégia de Modelagem de Features

Modelagem somente de features dinâmicas Modelagem de features

estáticas e dinâmicas

Múltiplos modelos Modelo único

Figura 4.2: Dimensão de variabilidade em DSPL.

dois tipos de variabilidades com as quais as soluções de DSPL podem lidar: (i) apenas variabilidade dinâmica; e (ii) variabilidades estática e dinâmica.

D2-A2. Modelo Conceitual de Variabilidade. Embora Kang e Lee [109] apresen- tem apenas dois modelos de variabilidade para SPLs (modelo de features e modelo de decisões), como discutido na Seção 2.3.3, nesta questão de projeto também são consi- deradas as outras estratégias para modelagem de variabilidade levantadas por Galter et al. [82]. Portanto, nessa classificação, a variabilidade pode ser representada como: (i) modelo de features; (ii) modelo de decisões; (iii) cenários de mudanças; (iv) perfis; (v) regras/condições; e (vi) rótulos de variantes/anotações. A representação da variabilidade como modelos de features é uma abordagem clássica usada pela maioria das soluções, sejam elas SPLs ou DSPLs. Já o modelo de decisões representa a variabilidade como um conjunto de decisões, comumente em notação tabular ou notação textual. No ter- ceiro tipo, as mudanças de cenários são modeladas para descrever eventos ou opções que acarretam em alterações no sistema. Na quarta abordagem, os perfis são criados para representar resumos descritivos de artefatos no ambiente (como uma tabela, um modelo ou um conjunto de expressões). Na representação de variabilidade como regras/condições, um conjunto de regras ou condições é definido para se referir a elementos ou artefatos que realizam o sistema, a fim de dar apoio à variabilidade. Na sexta e última abordagem, rótulos de variantes ou anotações são adicionados a artefatos que representam a DSPL.

D2-A3. Estratégia de Modelagem de Features. Existem pelo menos duas estra- tégias de projeto para a representação de features em DSPLs: (i) modelagem somente de features dinâmicas; e (ii) modelagem de features estáticas e dinâmicas. No primeiro caso, o modelo de features representa apenas features dinâmicas com binding dinâmico, abrangendo modelos de features derivadas da notação FODA, modelos OVM e CVL (Se- ção 2.3.3). No segundo caso, o mecanismo apoia features estáticas e dinâmicas ao mesmo tempo. Como mencionado na Seção 2.3.3, a maioria das notações tradicionais de modelos de features enfatizam apenas a variabilidade no espaço, não possuindo nenhuma repre- sentação específica para definir se o binding de um ponto de variação deve ser executado durante a fase de projeto ou durante a execução. Assim, há pelo menos duas estraté- gias de projeto para combinar features estáticas com features dinâmicas, representando a variabilidade no tempo: (i) uso de múltiplos modelos, com um modelo de features para representar todas as features (estáticas e dinâmicas) e um modelo separado que diferencia as features estáticas e dinâmicas ou para representar seus binding times, como, por exem- plo, os trabalhos desenvolvidos por Ferber et al. [77] e por Lee e Muthig [117]; e (ii) uso de apenas um modelo de features baseado em uma notação estendida para representar features estáticas e dinâmicas, como o realizado por Lee et al. [116].

D2-A4. Modelo Arquitetural. Existem pelo menos duas técnicas de projeto para a representação de arquiteturas de linhas de produtos (PLA) (Seção 2.3.4): (i) usar lingua- gens personalizadas; e (ii) usar ADL. No primeiro caso, algumas soluções de DSPL definem linguagens personalizadas ou modelos ad hoc para representar o modelo arquitetural. No segundo caso, as ADLs são usadas para definir a arquitetura do software.

D2-A5. Estilo Arquitetural. Este aspecto refere-se às entidades altamente granu- lares do sistema e como elas estão conectadas entre si [27]. Há pelo menos três estilos arquiteturais diferentes utilizados por soluções de DSPL: (i) baseado em componentes; (ii) orientado a serviços; e (iii) híbrido. No primeiro estilo, as arquiteturas baseadas em componentes fornecem as funcionalidades dos sistemas estruturados como configurações arquiteturais compostas de componentes e conectores. No segundo estilo, as arquiteturas orientadas a serviços são baseadas em serviços para fornecer funcionalidades de sistemas aos clientes de serviços. No último, os estilos arquiteturais híbridos são baseados em componentes e serviços, usando especificações como a Service Component-Architecture (SCA).

D2-A6. Elemento de Variabilidade. O elemento gerenciado de variabilidade é a parte do sistema que muda quando ocorre a resolução da variabilidade. A variabilidade pode ser anexada a diferentes tipos de elementos, tais como: (i) código; (ii) componentes; (iii) serviços; (iv) aspectos; e (v) arquiteturas de software. No primeiro caso, a variabi- lidade promove mudanças no código, que é gerado, compilado e implantado em tempo de execução. No segundo caso, a variabilidade é anexada aos componentes, permitindo a conexão e a desconexão dos componentes. No terceiro caso, a variabilidade promove mudanças no nível de serviço, permitindo a conexão e desconexão de serviços. No quarto caso, a variabilidade dinâmica é realizada por um aspect weaver dinâmico. No último caso,

duas ou mais arquiteturas são comparadas para atender a variabilidade, como realizado em [37].

D2-A7. Rastreabilidade da Variabilidade. Esta questão de projeto refere-se ao mapeamento entre a variabilidade e os modelos arquiteturais. Existem pelo menos três estratégias para apoiar a rastreabilidade: (i) ligação direta; (ii) matriz de rastreabilidade; ou (iii) regras de transformação. Na primeira estratégia, uma ligação direta é definida entre os elementos de variabilidade e os elementos arquiteturais. Isso pode ser realizado, por exemplo, usando OVM ou CVL para relacionar features com elementos arquiteturais ou usando estereótipos em componentes do modelo arquitetural como uma referência às features do modelo de features. Essa estratégia não exige que outro artefato especifique a rastreabilidade, uma vez que ela é implicitamente definida no modelo de variabilidade ou no modelo arquitetural. Na segunda estratégia, a matriz de rastreabilidade é realizada em uma tabela ou modelo de mapeamento dos elementos do modelo de variabilidade para elementos do modelo arquitetural. Na última estratégia, as regras de transformação definem a rastreabilidade entre variabilidade e modelo arquitetural.

D2-A8. Plataforma. Nesta questão de projeto, a tecnologia utilizada para implemen- tar a DSPL pode ser classificada em quatro categorias: (i) modelo de componentes; (ii) modelo de serviços; (iii) framework ou API; e (iv) ferramenta. O modelo de componentes define o padrão e as convenções impostas aos componentes do sistema para descrever suas funções e interações. O modelo de serviços define os padrões e protocolos usados para implementar e vincular serviços. A terceira categoria (framework ou API) refere-se à infraestrutura usada como base para a construção do sistema e geralmente corresponde a uma implementação de um modelo de componente ou de um protocolo de serviço com uma linguagem de programação específica. Por fim, as ferramentas de apoio referem-se aos sistemas de software utilizados para a construção de DSPL. A Tabela 4.1 lista as opções encontradas para cada uma das categorias listadas.