Um modelo de features modela todos os produtos possíveis de uma LPS (BENAVI- DES et al., 2010). Kang et al. (1990) definem uma feature como uma característica do sistema visível ao usuário final. Já Gurp et al. (2001) caracterizam feature como sendo uma unidade lógica de comportamento que corresponde a um conjunto de requisitos funcionais e de qualidade. Segundo Gurp et al. (2001), existe uma relação n:m entre features e requisitos. Isto significa que um determinado requisito pode ser aplicado a várias features e uma feature em particular pode abranger mais de um requisito.
Embora os modelos de features sejam estudados na engenharia de domínio de uma LPS, estes modelos de informação podem ser utilizados para outras áreas que vão desde a coleta dos requisitos, bem como a estrutura do modelo de dados. Daí a importância dos modelos de featuresno domínio de sistemas de informação (BENAVIDES et al., 2010).
A estrutura de um modelo de features é representado como um conjunto hierarqui- zado de features composta por (BENAVIDES et al., 2010):
• Relações entre uma feature pai e suas features filhas (ou subfeatures); e
• Restrições (ou cross–tree) que são tipicamente declarações de inclusão ou exclusão de features. Como por exemplo, se a feature F é incluída, então features A e B também devem ser incluídas (ou excluídas).
A Figura 5 apresenta um exemplo de modelo de features e uma representação gráfica dos conceitos básicos, baseados na notação Feature-Oriented Domain Analysis (FODA) (KANG et al., 1990). Kang et al. (1990) definiram pela primeira vez o termo modelo de features, e propuseram a primeira notação para o modelo de features, do método denominado FODA (Feature–Oriented Domain Analysis). Os modelos de features básicos são baseados na notação do método FODA e possuem as seguintes relações entre as features (BENAVIDES et al., 2010): • Obrigatória ou Mandatória: A feature filha tem o relacionamento obrigatório com seu pai, quando a filha é incluída em todos os produtos em que sua feature pai aparece. Por exemplo, no modelo de features representado na Figura 5, o sistema Mobile Phone deve conter a feature Calls;
• Opcional: Uma feature filha tem um relacionamento opcional com seu pai, quando a filha pode ser opcionalmente incluída em todos os produtos em que a sua feature pai aparece. No modelo de features da Figura 5 a feature GPS é opcional, portanto, os produtos para Mobile Phone podem opcionalmente incluir suporte para a feature GPS;
• Alternativa ou XOr: Um conjunto de features filhas têm uma relação alternativa com o seu pai, quando apenas uma feature filha pode ser selecionada, quando a feature pai é parte do produto. Como por exemplo, na Figura 5, o modelo Mobile Phones pode incluir suporte para as features basic, colour ou high resolution screen, mas apenas para uma destas features; e
• Or: Um conjunto de features filhas pode ter relacionamento com seu pai, quando uma ou mais dentre elas podem ser incluídas nos produtos em que sua feature pai aparece. No modelo de features descrito na Figura 5, por exemplo, sempre que a feature Media é selecionada, Camera, MP3, ou ambas as features podem ser selecionadas.
Segundo Benavides et al. (BENAVIDES et al., 2010), uma feature filha só pode aparecer em um produto se a feature pai faz parte do produto. A feature raiz é parte de todos os produtos derivados da LPS. Além das relações de parentesco entre as features, um modelo de featurestambém pode conter restrições entre as features. Estes são tipicamente da forma:
• Require: Se uma feature A requer uma feature B, ou seja, a inclusão de A em um produto implica a inclusão de B. Na Figura 5, Mobile Phones incluem uma feature Camera para poder incluir suporte para a feature High Resolution Screen; e
• Exclude: Se uma feature A exclui uma feature B, ambas as features não podem ser parte do mesmo produto. Na Figura 5, GPS e Basic Screen são features incompatíveis.
Figura 5 – Exemplo de um modelo de features básico (adaptado de (BENAVIDES et al., 2010)) Alguns autores estendem os modelos de features na notação do método FODA (KANG et al., 1990) com recursos da UML, como, por exemplo, a multiplicidade (também chamado cardinalidade). A cardinalidade é utilizada para definir o número mínimo e máximo de featuresvariáveis que podem ser escolhidas a partir de um ponto de variação.
Essas relações introduzidas no modelo de features são definidas por Benavides et al. (BENAVIDES et al., 2010), como:
• Cardinalidade de Feature: é uma sequência de intervalos indicados [n..m] com n como limite inferior e m como limite superior. Estes intervalos determinam o número de instâncias da feature que pode ser parte de um produto. Esse relacionamento pode ser usado como uma generalização das features obrigatórias ([1,1]) e opcionais ([0,1]); e • Grupos de Cardinalidade: é um intervalo denotado por <n..m>, onde n representa o
limite inferior e m o limite superior limitando o número de features filhas que podem ser parte de um produto quando a feature pai é selecionada. Assim, uma relação alternativa ou XOr é o equivalente a <1..1> e uma relação Or é equivalente a <1..n>, sendo n o número de features no relacionamento.
A modelagem da variabilidade em LPSs não inclui a modelagem de informações do contexto, consideradas informações essenciais para o desenvolvimento de aplicações dinâmicas e adaptativas. Para o desenvolvimento desse tipo de aplicação, surgiram as LPSDs, que são capazes de se adaptar às variações das necessidades dos usuários e às evoluções das restrições dos recursos, conforme mencionado na Seção 2.1.
Em LPSD, além das propriedades apresentadas para modelar a variabilidade no modelo de features, deve-se representar também a variabilidade dinâmica baseada em contexto. Para isso, Capilla, Ortiz e Hinchey (CAPILLA et al., 2014b) propõem duas estratégias:
Figura 6 – Formas de representar a variabilidade dinâmica baseada em contexto em modelos de features(adaptado de (CAPILLA et al., 2014b))
• Dois modelos de features relacionados: uma das estratégias é representada no modelo de features do lado esquerdo da Figura 6, o qual mostra o modelo de features separado das featuresde contexto. As dependências entre as features de contexto e as features comuns sobrecarregam as relações entre features, e essas dependências podem ser bidirecionais; e • Um único modelo de features: outra estratégia é representada no modelo de features do lado direito da Figura 6, onde features de contexto (as que são afetadas por adaptações de contexto) e features que não são de contexto são modeladas no mesmo modelo de features, o que reduz o número possível de dependências entre as features. As features de contexto são simplesmente rotuladas no modelo de features e classificadas de acordo com um conjunto de tipos pré-definidos. As features em verde e em vermelho são, respectivamente, aquelas features de contexto que são ativadas e desativadas em um determinado momento. Além das restrições do modelo de features, deve-se tratar com as regras inerentes ao contexto. As regras de contexto devem ter informações de contexto inerentes ao ambiente e devem prever as dependências com o modelo de features.
Mens et al. (MENS et al., 2016) definem uma taxonomia para abordagens para representação da variabilidade de LPSDs em sistemas sensíveis ao contexto. A taxonomia classifica as abordagens por:
• Mecanismos de variabilidade suportados: aborda diferentes técnicas para representar e gerenciar a variabilidade a fim de apoiar a as mudanças de contexto do sistema. Como os sistemas sensíveis ao contexto normalmente usam informações contextuais na pós- implantação e em tempo de execução, foram classificados apenas os mecanismos de
variabilidade suportados por modelos de variabilidade dinâmicos;
– Variabilidade dinâmica fechada: suporta a ativação e desativação dinâmica de features que foram predefinidas;e
– Variabilidade dinâmica aberta: suporta adição, remoção e modificação (e.g., substi- tuição de uma feature opcional por uma obrigatória) de features dinamicamente. • Tipos de features: diferentes tipos de features por parte do tipos de sensibilidade ao
contexto que eles suportam, variando de features muito estáticas que não são sensíveis ao contexto, por meio de features tradicionais que implementam a sensibilidade ao contexto internamente ou a sensibilidade ao contexto implementada por meio de variações de featu- res, com abordagens de programação orientada ao contexto que têm uma representação de primeira classe explícita de contextos e suas correspondentes adaptações comportamentais; e
– Features contextuais: variam ligeiramente com os dados do contexto específico, mas essas variações são internalizadas na feature;
– Features não contextuais: usadas quando as variações são escolhas estáticas não desencadeadas pelo contexto dinâmico; e
– Features de contexto: representam variantes contextuais específicas de uma feature que são apenas relevantes em contextos particulares.
• Dependências: dependências entre features desempenham um papel fundamental na modelagem e representação da variabilidade. A taxonomia centra-se sobre as alternativas existentes para estabelecer relações entre features de contexto e não contextuais.
– Árvore de contexto com dois galhos separados: usa um único modelo features (árvore) com dois ramos separados para representar tanto tanto as features de contexto quanto as features não-contextuais;
– Árvore de contexto com um galho: features de contexto e não-contextuais são inseridas em uma único modelo de features; e
– Dependências declaradas pelo programador: declarar explicitamente as dependências entre os contextos em um código orientado para o contexto.
Baseado nessa taxonomia, a avaliação de qualidade nesse trabalho será utilizada a representação do modelo de features de LPSD com: (i) mecanismo de variabilidade dinâmica fechado; (ii) features não contextuais e de contexto; e (iii) dependências em um modelo de featuresúnico.
Figura 7 – Exemplo de modelo de features com contexto Smart Home - adaptado de (CAPILLA et al., 2014a)
Em LPSDs, alguns trabalhos têm se utilizado da modelagem do contexto juntamente ao modelo de features (SALLER et al., 2013; CAPILLA et al., 2014a), outros utilizam o modelo de contexto separado do modelo de features (FERNANDES et al., 2011; ALFÉREZ et al., 2014a; GAMEZ et al., 2015).
A Figura 7 apresenta um exemplo de modelo de features que representa features de contexto para o domínio de sistemas smart homes (CAPILLA et al., 2014a). Em uma determinada configuração atual do modelo de features, são representadas as features ativas e inativas de um determinado contexto, assim como as restrições, relacionamentos e features obrigatórias e opcionais do modelo de features.
No exemplo da Figura 7, as funcionalidades de controle do sistema podem ser ativadas por meio do celular. Caso o usuário deseje utilizar a feature vídeo on-demand, a configuração atual não é válida até vídeo on-demand ativar a configuração de internet (que no exemplo estar desativado). Consequentemente, uma operação de explicação da configuração utiliza técnicas de diagnóstico para determinar quais features devem mudar seu estado para alcançar uma configuração de produto válida em tempo de execução. Nesta situação, é possível obter quatro possíveis reconfigurações, uma para cada tipo de conexão com a Internet: WiFi-b/g, Wi-fi-n, Ethernet e protocolos 3G. O critério de desempate para escolher a melhor configuração pode ser com base em atributos de qualidade exigidos pelas configurações do usuário ou do sistema desejado, como a da taxa de largura de banda disponível. Uma vez que o algoritmo determina a ideal ou correta configuração, as features podem mudar seus valores para os estados
válidos uma vez que as restrições e dependências tenham sido satisfeitas.