Modelo de Features

Uma Feature é uma característica de um produto que utilizadores e clientes consideram importante, na descrição e distinção de membros de uma família de produtos. Pode ser um requisito específico ou uma selecção entre os requisitos específicos e alternativos.

37

Uma feature é, também, uma propriedade do sistema usada para distinguir os requisitos comuns dos requisitos variáveis de uma LPS. Pode estar relacionada com certas características do produto como funcionalidade, usabilidade e desempenho, assim como também pode estar relacionada às características de implementação como o tamanho, a plataforma de execução ou compatibilidade com certos padrões.

O modelo de features foi introduzido como parte do método FODA, e representa uma hierarquia de propriedades de conceitos do domínio. É uma das técnicas mais bem sucedidas para facilitar a reutilização de artefactos de software. O modelo de features é uma representação hierárquica, que visa captar os relacionamentos estruturais entre as features de um domínio de aplicação. O modelo também representa as features comuns e variáveis de instâncias de conceitos (por exemplo, sistemas de software) e dependências entre as features variáveis. Um modelo de features consiste em um diagrama composto de features e alguma informação adicional, tais como descrições semânticas de cada feature, pontos variáveis, motivos (i.e. rationale) para cada feature, prioridades e regras de dependência.

No contexto das linhas de produto de software, um modelo de features representa a própria linha de produtos.

Uma feature pode ser de um dos seguintes tipos:

• Obrigatória: A feature tem de estar presente em todos os membros da linha de produtos.

• Opcional: A feature pode ou não estar presente em um membro da linha de produtos.

• Alternativa: É uma feature que é composta de um conjunto de features das quais se escolhe uma ou mais, devendo-se indicar se é necessário escolher apenas uma ou se se pode escolher mais que uma. Nestas features é necessário fazer a distinção de alternativas OR, que permite mais do que uma feature, e XOR, que mostra a exclusão mútua.

Uma feature obrigatória é representada por uma aresta terminada por um círculo preenchido a preto. Uma feature opcional é representada por uma aresta terminada por

38

um círculo vazio. As features alternativas são representadas por arestas que estão ligadas e conectadas por um arco. Se o arco for vazio deve-se escolher apenas uma das alternativas (XOR), se for preenchido é permitido escolher mais de uma alternativa (OR) (notação de Van Deursen e Klint, 2002).

O modelo de features também introduz duas regras de decomposição: “requires”, que permite adicionar uma determinada feature a uma instância solicitada, e “mutex-with”, que permite fazer o inverso.

Czarnecki (Czarnecki et al., 2004) propõe colocar cardinalidade nas features para poder remover ambiguidades e representar a informação mais facilmente, sendo as diferentes cardinalidades assim definidas:

• 0..1 – Pode-se escolher uma ou nenhuma feature do conjunto de sub-features. • 1 – Exactamente uma feature tem de ser escolhida de um conjunto de sub-

features.

• 0..* - Um número arbitrário de features (ou nenhuma) tem de ser seleccionado do conjunto de sub-features.

• 1..* - Pelo menos uma feature tem de ser seleccionada do conjunto de sub- features.

Para o caso de estudo apresentado, através do modelo de features, podemos representar as principais funcionalidades do mesmo. A Figura 3.3 mostra uma possível representação para o modelo de features do Sistema de abastecimento de veículos, através de Via Verde, utilizando as notações referidas anteriormente.

Neste modelo são features obrigatórias o Pagamento e a Bomba, as features Reclamação, Identificador, Extracto e Adesão são features opcionais. A feature Adesão possui três sub-features obrigatórias, sendo elas: Formulário, Activação Multibanco e Recepção Identificador. A feature Extracto contém um grupo de sub-features numa alternativa XOR, que indica que apenas uma delas é escolhida para a aplicação. No caso da feature Pagamento, esta é composta por quatro sub-features numa alternativa OR, mas com cardinalidade, que indica que entre uma a quatro sub-features terão de ser usadas na

39

aplicação. Para o caso do pagamento com Via Verde, este encontra-se ligado com “requires” à feature Adesão, uma vez que o pagamento com via verde requer a adesão. A linha a tracejado da feature Activação Multibanco até à feature Recepção Identificador indica que a recepção do identificador está dependente da activação do mesmo no multibanco por parte do aderente, cuja ligação se denomina de “requires”. O mesmo sucede com as features Identificador e Recepção Identificador, uma vez que a feature Identificador está dependente da feature Recepção do Identificador.

Figura 3.3 Modelo de Features do Sistema de Abastecimento

3.6 Sumário

Neste capítulo foram apresentados os principais conceitos de ELPS. Primeiramente foi apresentada uma breve introdução às LPS, assim como algumas das suas vantagens e desvantagens. A ELPS é constituída por três actividades essenciais, sendo elas, o desenvolvimento de artefactos base, o desenvolvimento do produto e a actividade de gestão. A actividade de desenvolvimento de artefactos base é conhecida também por Engenharia de Domínio e a actividade de desenvolvimento do produto é conhecida por Engenharia de Aplicação. Cada um destes processos é composto por sub-processos. Os artefactos base formam a base das LPS e são os blocos de construção para que novos produtos sejam concebidos. O desenvolvimento de um produto específico é o principal propósito de uma LPS. Por fim, as actividades de gestão são cruciais para adoptar uma abordagem da LPS, uma vez que todos os recursos necessários são determinados nestas actividades.

40

Sendo a variabilidade uma propriedade central da ELPS, foi também apresentado o seu conceito nesta secção. Foram também apresentados os conceitos do modelo de features para documentar a variabilidade de uma LPS, sendo ilustrados através do modelo para o exemplo de abastecimento.

No Capítulo 4 serão apresentadas algumas das abordagens de engenharia de requisitos, aspectuais e não aspectuais, integradas com LPS.

41