Um dos principais conceitos em LPSs é a variabilidade, a qual pode ser definida como a possibilidade de configuração, ou ainda, como a habilidade que um sistema ou artefato de software possui de ser alterado, customizado, ou configurado para um contexto em particular (BOSCH, 2004).
A variabilidade para LPSs tradicionais é definida de forma estática, que corresponde a variabilidade que é implementada em tempo de projeto ou desenvolvimento (GALSTER et al., 2014). No entanto, em sistemas sensíveis ao contexto, a variabilidade estática é muitas vezes insuficiente porque não é possível predefinir como ativar ou desativar as features devido à imprevisibilidade do contexto (MURGUZUR et al., 2014). Portanto, para a implementação da variabilidade para esses sistemas em LPSDs, a variabilidade deve ser dinâmica.
A variabilidade de LPSDs é dinâmica, e é definida em tempo de execução. A variabilidade em tempo de execução define as escolhas do projeto de produtos visíveis aos clientes e usuários do sistema que podem ser selecionados entre as opções configuráveis disponíveis. A variabilidade em tempo de design é oculta para o usuário e gerenciada pelos desenvolvedores do produto, que podem decidir, por custo ou por outras razões, ativar determinadas opções de designem uma variante específica (CAPILLA; BOSCH, 2011).
Segundo Capilla et al. (2014b), muitos dos sistemas dinâmicos de software que usam propriedades contextuais são baseados em uma abordagem de linha de produto de software. No entanto, esta abordagem trata a variabilidade como um artefato de design estático que implementa as variações na arquitetura de software ou no modelo de features. Recentemente, a abordagem de LPSD foi descrita como um modo de promover o uso da variabilidade dinâmica e como um
mecanismo para gerenciar dinamicamente features de contexto para atender às necessidades de adaptação dinâmica (CAPILLA et al., 2014a).
A diferença entre a variabilidade estática e a variabilidade dinâmica é que na varia- bilidade estática as variantes são tipicamente definidas durante o ciclo de desenvolvimento. Já os modelos de variabilidade dinâmica, oferecem uma forma dinâmica para alterar e selecionar variantes em diferentes tempos de execução. A variabilidade em tempo de execução permite aos usuários a seleção de diferentes alternativas e permite reconfiguração em tempo de execução, enquanto que a variabilidade estrutural permanece inalterada (BOSCH; CAPILLA, 2012).
Segundo Bosch e Capilla (2012), a variabilidade dinâmica oferece a capacidade de reconfiguração dinâmica para sistemas que requerem adaptações contínuas ou periódicas. Desta forma, a dinâmica interna do sistema pode desencadear reconfigurações em tempo de execução para ativar e desativar features do sistema quando necessário, e essas features podem se adaptar ao comportamento do sistema para diferentes cenários.
A variabilidade dinâmica baseada em contexto estende a perspectiva tradicional de modelagem de features para sistemas que exploram as propriedades do contexto dinamicamente. Entretanto, a crescente complexidade dos sistemas críticos que exigem maiores capacidades dinâmicas requer algo mais, além de simplesmente ativar e desativar features. A combinação de características de contexto e técnicas de variabilidade dinâmicas é uma excelente maneira de fornecer mecanismos automáticos de reconfiguração para sistemas críticos sensíveis ao contexto (CAPILLA et al., 2014b).
A Figura 4 apresenta um conjunto de diferentes tipos de sistemas com propriedades dinâmicas, como: sistemas autoadaptativos, sistemas automáticos de computação, sistemas difusos, sistemas baseados em serviços e ecossistema de software. Além disso, Capilla e Bosch (2011) apresentam na Figura 4 propriedades da variabilidade dinâmica, conforme descritos a seguir:
• Modelos de variabilidade extensíveis: refere-se a capacidade de representar a variabili- dade, modificando pontos de variação e novas unidades de software durante a execução e reconfiguração automática do sistema. Capilla et al. (2014a) consideram este aspecto como uma das formas mais simples de gerenciamento de variações em tempo de execução, em que o usuário ou o sistema, de maneira automatizada, pode ativar/desativar features do produto dinamicamente.
tomatizar a variabilidade dinâmica e verificar os modelos de features que se reconfiguram em tempo de execução, para manter a consistência e estabilidade do produto. Capilla et al. (2014a) afirmam que quando uma dada mudança ocorre no produto, adição/desativação de features, é necessário garantir que o sistema encontra-se consistente, e que a mudança introduzida não condicionou dependências e/ou restrições no produto, que possam de- sencadear a ocorrência de erros na nova configuração. Estas dependências devem ser documentadas durante o processo de requisitos através de dependências entre as features associadas aos requisitos do produto.
• Implantação em tempo de execução: refere-se ao processo de automação de implantação do produto e reconfiguração dos produtos em tempo de execução com o mínimo de interrupções. Capilla et al. (2014a) acreditam que a reconfiguração em tempo de execução do produto deve ser entendida como a capacidade do sistema de garantir a reconfiguração quando uma dada mudança ocorre. Pascual et al. (2015) indicam que o processo de implantação de um produto pode ser feito de duas formas: (i) em tempo de projeto e em (ii) tempo de execução. Na implantação em tempo de projeto a montagem de todas as partes necessárias para todas as possíveis adaptações do produto ocorrem durante a montagem do produto para a sua entrega. Já na implantação em tempo de execução a conexão das partes necessárias para as possíveis adaptações do produto ocorrem à medida que surgem as necessidades de adicionar variabilidade ao produto.
• Rastreabilidade alinhada à arquitetura: refere-se à capacidade de rastreabilidade das variantes do modelo de features estar alinhado às variantes representadas na arquitetura da LPSD.
• Mecanismos de vinculação: para os binding times de LPSs, são necessários mecanismos de vinculação para conectar as diferentes partes do produto. Isso ocorre normalmente antes da execução de fato do produto, ainda na fase de projeto (HINCHEY et al., 2012).
Capilla et al. (CAPILLA et al., 2014a), ainda destacam os seguintes desafios de lidar com a variabilidade dinâmica em uma LPSD:
• Ativação e desativação de features de sistemas: a ativação e desativação de opções de sistemas (ou seja, features) é um das formas mais simples de gerenciar as variações em tempo de execução. O usuário ou o próprio sistema pode mudar de forma autonômica features on/off dinamicamente. Em alguns casos, o sistema pode precisar ser reconfigurado se as features dos sistemas críticos são mudadas, enquanto em outros casos, o estado do
Figura 4 – Mecanismos de variabilidade dinâmica necessários para a transição de LPSs para LPSDs - adaptado de (CAPILLA; BOSCH, 2011)
sistema continua a ser o mesmo.
• Mudanças automáticas na variabilidade estrutural: Ao contrário das LPSs tradicionais, onde modelos de variabilidade permanecem estáticos após o tempo de projeto, LPSs dinâmicas podem modificar a estrutura da variabilidade dinâmica. Alterar variantes de forma dinâmica e automaticamente é tecnicamente viável, mas mudar pontos de variação em tempo de execução requer alguma forma de intervenção humana. Adicionar e remover variantes tem implicações diretas para as restrições e dependências entre as variantes. • Dependências em tempo de execução e verificação de restrições: As mudanças no
modelo de features realizadas em tempo de execução podem exigir, em certos casos, algum tipo de verificação em tempo de execução para detectar novas incompatibilidades de configurações dos produtos, como variantes que mudam também podem introduzir novas alterações nas dependências e regras de restrições que podem ser modificadas em tempo de execução. Além disso, a validade do modelo de features deve ser verificada para evitar produtos inviáveis quando, por exemplo, um novo conjunto de features é selecionado. • Reconfiguração otimizada e dinâmica: reconfiguração dinâmica é uma propriedade
fundamental para LPSDs onde produtos de software precisam ser reconfigurados em tempo de execução. Como a verificação automatizada dos modelos de features é feita muitas vezes em modo estático, existe uma necessidade de fornecer mecanismos de reconfiguração otimizados que podem ser executados em tempo de execução quando variantes mudam.
• Mecanismos de reconfiguração: Muitos sistemas autônomos requerem uma camada de adaptação para adaptar o comportamento do sistema para as novas condições. A ativação e mudança em uma feature do sistema muitas vezes conduz esse comportamento para adaptar o sistema para novas condições de qualidade ou a um novo ambiente.
• Múltiplos binding e rebinding: Produtos de uma LPSD podem requerer múltiplos binding times. Tal como as linhas de produto tradicionais são concebidas para suportar um único tempo de ligação, na maioria dos casos, a dinamicidade de modelos de LPSD deve oferecer múltiplos binding times para alternar entre diferentes modos de operação.
• Variabilidade do contexto: Os modelos de features tradicionais representam as features do sistema e não as features de contexto utilizadas para detectar e gerenciar as condições de contexto. Portanto, a noção de variabilidade de contexto concentra-se na identificação e modelagem das propriedades de contexto que são especificamente concebidas para lidar com a diversidade do contexto que influencia o comportamento dinâmico dos sistemas.