ABORDAGENS DE DOCUMENTAÇÃO DE
VARIABILIDADE EM LINHA DE PRODUTO DE
SOFTWARE
JEAN POUL VARELA
Recife,
2014
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
JEAN POUL VARELA
ABORDAGENS DE DOCUMENTAÇÃO DE
VARIABILIDADE EM LINHA DE PRODUTO DE
SOFTWARE
Monografia apresentada ao Curso de pós-graduação
em Ciência da Computação, Centro de Informática,
Universidade Federal de Pernambuco, como requisito
parcial para conclusão da disciplina Engenharia de
Requisitos.
Professor: Prof. Jaelson Brelaz de Castro
Recife,
2014
Sumário
Resumo ............................................................................................................................. 6
1 Introdução ...................................................................................................................... 8
2 Linha de Produto de Software ....................................................................................... 9
3 Caso de Uso ................................................................................................................. 12
4 Orientação a Aspecto ................................................................................................... 12
5 Exemplo ....................................................................................................................... 13
5.1 Featuares obrigatórias do eShop ........................................................................... 14
5.2 Featuares variáveis do eShop ............................................................................... 15
6 Abordagens .................................................................................................................. 16
6.1 PLUSS .................................................................................................................. 16
6.1.1 Modelagem de Caso de Uso .......................................................................... 17
6.1.2 Instanciação de produto ................................................................................. 20
6.1.3 Exemplo ......................................................................................................... 20
6.2 PLUC .................................................................................................................... 21
6.2.1 Modelagem de Caso de Uso .......................................................................... 21
6.2.3 Exemplo ......................................................................................................... 22
6.3 MSVCM ............................................................................................................... 23
6.3.1 Feature Model ................................................................................................ 24
6.3.2 Modelo de Caso de uso.................................................................................. 24
6.3.3 Configuration Knowledge (CK) .................................................................... 26
6.3.4 Configuração do Produto ............................................................................... 26
6.3.5 Exemplo ......................................................................................................... 27
6.4 VML4RE .............................................................................................................. 29
6.4.1 Representação da Variabilidade .................................................................... 29
6.4.2 Exemplo ......................................................................................................... 30
6.5 MODEL TEMPLATE .......................................................................................... 33
6.5.1 Exemplo ......................................................................................................... 35
6.6 PLUS .................................................................................................................... 37
6.6.1 Modelagem de Caso de Uso .......................................................................... 37
6.6.1.1 Modelagem para Pequenas Variações .................................................... 37
6.6.1.1.1 Modelagem de variante opcional para Pequenas Variações ............ 38
6.6.1.1.2 Modelagem de variante alternativa para Pequenas Variações......... 39
6.6.1.2 Modelagem para Variações Complexas ................................................. 39
6.6.1.2.1 Modelagem de variação complexa com relacionamento Extend .... 40
6.6.1.2.2 Modelagem de variação complexa com relacionamento Include .... 43
6.6.2 Exemplo ......................................................................................................... 45
6.6.2.1 Exemplo de modelagem de pequenas variações..................................... 45
6.6.2.1 Exemplo de variante opcional para pequenas variações .................... 46
6.6.2.2 Exemplo de variantes alternativas para pequenas variações .............. 46
7 Conclusão .................................................................................................................... 47
Bibliografia ..................................................................................................................... 49
Apêndice 1 ...................................................................................................................... 52
Lista de Figuras
Figura 1. Framework de desenvolvimento de LPS (Pohl, 2005) ................................... 10
Figura 2. Modelo de Feature do Sistema de Dipositivos Móveis (Torres, 2011)........... 11
Figura 3. Variabilidade da linha de produto eShop ........................................................ 14
Figura 4. Feature Model da Abordagem PLUSS (Eriksson et al, 2005). ....................... 17
Figura 5. (a) Blackbox flow of events usado para descrever cenários de uso; (b)
Whitebox flow of events usa do para descrever realização de caso de uso.................... 17
Figura 6. Meta Modelo de PLUSS ................................................................................. 18
Figura 7. Template de documentação com o conceitos de pluss ................................... 19
Figura 8. Notação de descrição de caso de uso proposto por (Cockburn, 2001)............ 21
Figura 9. Cenário Buy Products ..................................................................................... 23
Figura 10. Representação Waving Process (Bonifácio, 2010) . ..................................... 24
Figura 11. Configuração do Produto. ............................................................................. 27
Figura 12. Cenário Básico Buy Products ....................................................................... 30
Figura 13. Passos da variante VTR01 ............................................................................ 31
Figura 14. Modelo de Composição ShoppingCart ......................................................... 31
Figura 15. Passos da variante VRT02 ............................................................................ 31
Figura 16. Modelo de Composição Bonus ..................................................................... 32
Figura 17. Passos da variante VRT03 ............................................................................ 32
Figura 18. Modelo de Composição Update User Preferences ........................................ 32
Figura 19. Composição de uma Instancia (Czamecki, 2005) ......................................... 34
Figura 20. Configuração de Produto Retirada de (Czarnecki Antkiewicz, 2005) .......... 35
Figura 21. Especificação cenário Buy Products em Model Template ............................ 36
Figura 22. Template para descrever pontos de variação pequenos ................................ 38
Figura 23. Documentação da variante Light .................................................................. 38
Figura 24. Documentação da variante Display Language .............................................. 39
Figura 25. Diagrama de caso de uso de Check Out Customer (Gomaa, 2004) ............. 41
Figura 26. Documentação do caso de uso Check Out Customer ................................... 41
Figura 27. Extensão Pay by Cash ................................................................................... 42
Figura 28. Extensão Pay by Credit Card ........................................................................ 42
Figura 29. Caso de Uso Validate PIN ........................................................................... 43
Figura 30. Caso de Uso Validate PIN ............................................................................ 44
Figura 31. Caso de uso Withdraw Funds ........................................................................ 44
Figura 32. Caso de Uso Deposit Funds .......................................................................... 45
Figura 33. Cenário searches goods ................................................................................. 46
Figura 34. Variante Show similar results ....................................................................... 46
Figura 35. Caso de uso Register ..................................................................................... 47
Figura 36. Variante Search Options ............................................................................... 47
Figura 37. Descrição do Caso de Uso Cook Food .......................................................... 52
Tabela
Tabela 1. Especificação PLUSS do cenário Buy Products ............................................. 20
Tabela 2. Cenário Proceed to purchase .......................................................................... 25
Tabela 3. Representação do Advice ADV03 .................................................................. 25
Tabela 4. CK do eShop ................................................................................................... 26
Tabela 5. Cenário Proceed to Purchase .......................................................................... 27
Tabela 6. Advice Buy a specific product ........................................................................ 28
Tabela 7. Advice Buy Products using a Shopping Cart ................................................ 28
Tabela 8. Advice Register User Preferences .................................................................. 29
Resumo
Tendo em vista a magnitude dos projetos de software desenvolvidos atualmente,
percebe-se a necessidade que o mesmo seja documentado, desde a fase de análise de
requisitos até a fase de projeto e implantação do sistema. Entre muitas abordagens
propostas para documentação pode-se citar a UML (UML, 2011).
Por outro lado, atualmente vem crescendo a necessidade por software com baixo
custo, com qualidade e que seja desenvolvido em um curto espaço de tempo. Neste
cenário vem ganhando força o paradigma de desenvolvimento baseado em linha de
produto software (LPS) (Pohl, 2005), a qual se concentra na reutilização de artefatos.
Uma LPS possui artefatos comuns e variáveis entre os produtos.
Tendo em vista este novo paradigma de desenvolvimento de software nota-se que a
documentação que era aplicada nos processo tradicional de desenvolvimento de
software já não é tão eficiente para o contexto de LPS, pois não possuem suporte a
variabilidade. Para contornar este problema, foram criadas algumas abordagens de
documentação de variabilidade em LPS.
Neste trabalho serão apresentadas técnicas para documentação de variabilidade em
linha de produto de sofware.
Palavras-chave: Linha de Produto de Software, Variabilidade, Documentação, Caso de
Uso.
6
7
1 Introdução
Tendo em vista que projetos de software variam em escala e complexidade, e
envolvem diversos recursos que vão desde recursos básicos até mesmo recursos
complexos, percebe-se a necessidade de um bom gerenciamento. Nos últimos anos a
abordagem de Linha de Produtos de Software (LPS) vem ganhando atenção, pois com o
desenvolvimento de software orientado a LPS é possível obter sistemas de alta
qualidade dentro de curtos prazos e com um baixo custo.
Um dos objetivos da LPS é o reuso de artefatos, como artefatos entendam-se
códigos fontes, testes e documentação (Pereira, 201)(Clements, 2001). A diferenciação
entre os produtos de uma LPS ocorre através da variabilidade, segundo (Clements,
2001) (Alferez, 2014), variabilidade de uma SPL é entendida como as semelhanças e
diferenças entre os produtos, em termos de requisitos, arquitetura, componentes e
artefatos de teste.
O gerenciamento de variabilidade durante a engenharia requisitos de SPL é essencial
para suportar a reutilização de requisitos (Bergmans, 2011). Este gerenciamento é
necessário para a adição e remoção de requisitos (Alferez, 2014). Para o gerenciamento
de variabilidade em requisitos é necessário que seja realizada a documentação da
variabilidade.
Nota-se que cenários são muitos utilizados na engenharia de linha de produtos de
software, pois com os mesmo é possivel obter um melhor entendimento das
caracteristicas da LPS (Alferez, 2014). Um "cenário de uso" descreve um exemplo real
de como um ou mais atores (por exemplo, usuários, organizações) interagem com o
sistema, descrevendo os passos que ocorrem durante a interação (Alexander, 2004).
Neste tabalho será apresentado abordagens para documentação de variabilidade em
linha de produto de sofware. Para cada técnica será apresentado um exemplo de
aplicação da mesma com o eShop Product Line (Pohl, Metzger; 2006) com o intuito de
demonstrar como é realizada a utilização da mesma.
O restante do trabalho está estruturado da seguinte forma, no capítulo 2 é apresentada
uma visão geral da abordagem LPS. No capítulo 3 é apresentada uma visão geral sobre
casos de uso. No capítulo 4 é apresentanda brevemente a abordagem de
desenvolvimento de orientação a aspecto, a qual é utilizada em uma abordagem. No
capítulo 5 é apresentada uma descrição da linha de produto eShop. No capítulo 6 são
8
apresentadas as técnicas de documentação de variabilidade. Finalmente no capítulo 7
são realizadas as considerações finais deste trabalho.
2 Linha de Produto de Software
Linha de Produto de Software (LPS) é um paradigma de Engenharia de Software que
propõe o desenvolvimento de sistemas voltado ao reuso estratégico (Pohl, Linden,
2005). O que uma LPS compartilha podem ser: features, requisitos, arquitetura,
decisões de projeto, código, artefatos de testes, linguagens, entre outras características
de produto e de processo de desenvolvimento (Bonifácio, 2010).
Segundo (Clements, Northrop; 2001) uma LPS é um conjunto de sistemas de
software que compartilham um conjunto comum e gerenciado de features para satisfazer
necessidades de um segmento particular de mercado ou missão, que são desenvolvidos a
partir de um conjunto de artefatos comuns (core asset) pré-definidos. Segundo (Parnas,
1976)
é uma família de produto gerada automaticamente a partir de componentes
reutilizáveis. A LPS visa atender a necessidade de um segmento do mercado especifico
com objetivo de oferecer a diversidade e customização de produtos de um segmento de
mercado.
Através da utilização de LPS é possível obter alguns benefícios, tais como citado por
(Nascimento, 2008) (Silva, 2011) entre outros se podem destacar: Aumento da
qualidade, pois uma vez que os artefatos numa LPS serão reutilizados em outros
produtos e consequentemente revisados e testados, assim tendo maiores chances de
detecção e correções de falhas, assim, aumenta a qualidade de todos os produtos.
Redução do esforço de manutenção: uma vez que os artefatos da linha possuem maior
qualidade, eles podem ser reutilizados com maior eficiência. Uma vez que as mudanças
serão propagadas em todos os produtos em que estes artefatos sejam utilizados e assim
os produtos apresentarão uma redução de defeitos. Redução dos custos de
desenvolvimento é devido às potencialidades propiciadas pelo reuso, as preocupações de
desenvolvimento envolverão a evolução do produto e o melhoramento das
funcionalidades. Uma visão baseada no crescimento, em novos investimentos, não na
manutenção ou “reinvenção da roda”. Redução do tempo para o produto chegar ao
mercado é alcançada uma vez que depois de certo tempo a base de artefatos
reutilizáveis dará suporte à criação dos produtos da linha, assim os produtos são criados
a partir da seleção de artefatos do core assets;
9
O processo de desenvolvimento de LPS é dividido em duas principais etapas (Pohl,
2005): (i) engenharia de domínio é responsável por dentre outras atividades, definir
quais são as aplicações que a LPS irá atender, definir quais as partes comuns e variáveis
da SPL, qual será a arquitetura de referência, e definição de artefatos que atendem as
variações da LPS; e (ii) é na a engenharia de aplicação em que uma configuração do
produto é gerada e depois é aplicado o processo de derivação de produto, que combinará
os artefatos da LPS em um novo produto. Tanto a engenharia de domínio quanto a
engenharia de aplicação são compostas por diversas atividades, as quais são
apresentadas na figura 1.
Figura 1. Framework de desenvolvimento de LPS (Pohl, 2005)
A implementação de LPS pode ocorrer de três formas segundo (Krueger, 2001):
(i)
proativa, em que a LPS é construída desde suas fases iniciais, contemplando
análise de domínio, projeto de domínio e implementação de domínio, todos
os produtos são projetados antecipadamente, está é considerada a
implementação ideal, porém não é a realidade de muitos cenários
encontrados, já que o software foi projetado e desenvolvido em aplicações
diferentes;
(ii)
extrativa, em que já existem diversos produtos que contêm características
comuns e variáveis, porém, não fazem parte do mesmo software, são
aplicações independentes, nesta forma de implementação, as características
variáveis de cada produto são isoladas e a parte comum compõe o núcleo da
aplicação;
10
(iii)
reativa, na qual já existe uma LPS, que é desenvolvida gradualmente, isto é,
conforme surgem necessidades de novos produtos, a LPS é ampliada com
seus artefatos comuns sofrendo extensões e criando novos artefatos variáveis
específicos para o novo produto em demanda.
Um conceito fundamental para abordagem de linha de produto de software é o
conceito de feature. De acordo com (Czarnecki, 2000) uma feature pode ser vista como
uma funcionalidade ou propriedade da LPS que permite distinguir os membros de uma
família. É necessário realizar um bom gerenciamento variabilidade de features (Torres,
2011).
Segundo (Torres, 2011) a abordagem precursora de gerenciamento de variabilidade é
a abordagem Feature-Oriented Domain Analysis (FODA) (Kang et al, 1990). Esta
técnica de gerenciamento propõe o modelo de features, neste modelo são representadas
as variabilidades de uma LPS. Neste modelo as features poderão ser dos seguintes tipos:

obrigatória, isto é uma feature que obrigatoriamente fará parte de todos os
produtos gerados;

opcionais, é uma feature que depende da seleção pelo engenheiro da aplicação
para que os artefatos associados sejam inclusos em um determinado produto,
caso contrário, estes artefatos não serão incluídos no produto final;

alternativas, que representam os grupos de features, uma feature alternativa
pode agrupar duas ou mais features, podendo ser mutuamente exclusivas.
Na figura 2 é apresentada a representação gráfica de um modelo de features, o modelo
em questão representa a variabilidade da LPS de dispositivos móveis, a qual está
apresentada em (Torres, 2011).
Figura 2. Modelo de Feature do Sistema de Dipositivos Móveis (Torres, 2011)
11
3 Caso de Uso
Caso de uso é um conceito fundamental na modelagem de sistemas, o mesmo faz
parte da especificação da UML (do inglês, Unified Modeling Language). Segundo
(UML, 2011) casos de uso são um meio de especificar o uso de um sistema por atores.
Um ator é qualquer entidade externa que interage com o sistema. O comportamento de
um sistema pode ser descrito por um ou mais casos de uso, os que são definidos de
acordo com as necessidades dos atores. Escrever casos de uso é, essencialmente,
descobrir e documentar requisitos funcionais, escrevendo estórias de uso do sistema que
ajudam a satisfazer os objetivos dos stakeholders (Larman, 2004).
Relacionado a caso de uso está o conceito de cenários que são uma sequência
específica de ações e interações entre atores e o sistema em questão, também podem ser
chamados de instâncias de caso de uso (Larman, 2004). Um caso de uso pode gerar
vários cenários. Cenários de uso podem ter cenários primários e secundários segundo
(Santander, 2002) aonde se considera que cenário primário é o caminho básico para
realizar um caso de uso, sem problemas e sem erros em nenhum dos passos da
sequência. Enquanto cenários secundários ou alternativos descrevem sequências
alternativas e de erros, que podem ocorrer em um cenário primário associado com um
caso de uso.
4 Orientação a Aspecto
A Programação Orientada a Aspectos (KICZALES et al, 1997) é um paradigma de
desenvolvimento de software que tem por objetivos à unificação dos códigos
secundários (crosscutting concerns) ao código principal. Segundo (Loureiro, 2010) o
mecanismo da Programação Orientada a Aspecto busca separar os interesses
transversais das classes em módulos bem definidos e centralizados, nos quais um
analista pode dedicar-se a um interesse de forma independente.
A orientação a aspectos é um paradigma que foi desenvolvido com os objetivos de
suprir deficiências dos outros paradigmas, segundo (BECKER, 1998) existem
problemas de programação que as técnicas de programação orientada a objetos ou de
programação estruturada não conseguem resolver, pois as mesmas não são suficientes
para separar claramente todas as decisões de projeto que o programa deve implementar.
Mesmo com todos os recursos disponibilizados nos paradigmas citados anteriormente,
12
ainda pode-se notar o espalhamento de código. A orientação a aspectos tenta suprir estas
falhas através da utilização de aspectos transversais ao comportamento do sistema.
A seguir serão apresentados alguns conceitos de orientação a aspectos que serão
relevantes para o entendimento das abordagens presentes neste trabalho, para mais
informações sobre orientação a aspectos recomenda-se a leitura de (KICZALES et al,
1997).
 Interesse: é uma característica, um requisito, algoritmos, uma funcionalidade.
Interesses podem ser de dois tipos:
o
Interesses funcionais (ou core concerns): são requisitos do domínio da aplicação.
o Interesses sistêmicos: são os requisitos que dão suporte aos interesses funcionais. Estes
interesses sistêmicos são à base do paradigma de programação orientado a aspecto.
 Aspectos: Um aspecto é a unidade fundamental de programação orientada a
aspecto. Segundo (Safonov, 2008) “Aspecto é uma parte de um programa
orientado a aspecto que separa os interesses ortogonais dos interesses
principais”. Um aspecto é uma estrutura que comporta todos os elementos da
orientação a aspecto. Assim com uma classe de orientação a objeto, um aspecto
também possui um nome, modificadores de acesso.

Pontos de junção (join points): segundo (Safonov, 2008) “O ponto de junção é
um ponto bem definido na execução de um sistema”. Os pontos de junção
podem ser qualquer parte local de um código. São nos pontos de junções que
diferentes interesses são ligados.
 Pontos de Atuação (pointcuts): são elementos do paradigma que identifica em
que ponto um determinado aspecto será combinado. Basicamente, os pointcuts
são regras para definir os eventos que os pontos de junção irão atuar.
 Adendos (advices): São pedaços de código que serão executados nos pontos de
junção. Então cada advice tem o seu pointcut e seu código associado.
5 Exemplo
Para exemplificar as abordagens apresentas neste trabalho será utilizado o exemplo
The eShop Product Line (Pohl, Metzger, 2006). O eShop é uma linha de produto de
sistemas de vendas de produtos online. Sendo que através desta a loja poderá vender os
produtos para os seus clientes através da internet.
A variabilidade desta linha de produto é apresentada na parte direita da figura 3, a
variabilidade é descrita com base na abordagem OVM (Pohl et al, 2005). Sendo que os
13
triângulos representam os pontos de variação, os retângulos representam as variantes e a
relação entre eles descrevem as restrições das escolhas das variantes.
Figura 3. Variabilidade da linha de produto eShop
5.1 Featuares obrigatórias do eShop
Todos o produto gerados da linha de produto irão possuir as features Register
customer, buy product and search product. As mesmas são descritas a seguir:
 Search product: realizada a pesquisa de produtos, essa pesquisa poderá ser
realizada através realizada através nome do produto ou um número de ordem.
 Buy product (Buy Goods): este caso de uso permite o cliente comprar um
produto. Este caso de uso inclui o caso de uso Search Product. Cada produto
14
que o cliente quer comprar é colocado em um carrinho de compras. Uma vez
que o cliente quer para completar a sua compra ele faz check-out e paga sua
compra, assim provocando a expedição das mercadorias.
 Register Customer: este caso de uso permite o cliente se registrar no eShop.
Antes de o cliente compra qualque produto ele primeiramente precisa realizar o
seu cadastro.
5.2 Featuares variáveis do eShop
Esta linha de produto contém 5 variantes, as quais serão apresentadas a seguir:
VP1 - Register Type : este ponto de variação diz a respeito do tipo que registro
que o cliente deverá fazer quando o mesmo for se cadastrar, pode fazer o registro
normal ou registro completo. Sendo que o registro normal, o cliente deve
fornecer o seu email e seu endereço postal. Já no registro completo, além de
inserir informações sobre o endereço de email e postal o cliente tem que
informar dados de sua conta bancária.
VP2 – Bonus: o sistema ainda disponibiliza a opção de o produto contar com
bônus ao cliente, o bônus é um ponto de variação mutuamente exclusivo, sendo
que as alternativas são Points ou Deduction. O bônus Points é oferecido com
base nos produtos em que o cliente já comprou, ou seja, a cada compra o cliente
adquire certa quantidade de ponto e após trocar por um determinado bônus, já no
bônus Deduction o cliente é feita a dedução diretamente no preço do produto.
VP3: Payment Type: a linha de produto oferece dois tipos de pagamento. O
cliente poderá pagar através de fatura (invoice) ou através de cartão (card). Caso
o pagamento seja realizado invoice a variante o ponto de variação VP1 deverá
ser do tipo Completely, O mesmo produto poderá possuir os dois tipos de
pagamento.
VP4: Card Type: há duas formas de pagamento, poderá ser realizada através de
credit ou através de debit. Sendo que essa escolha é mutuamente exclusiva.
15
VP5: Search Options: o cliente pode procurar um produto, digitando o nome do
produto ou o número do pedido do produto utilizando o caso de uso de não
poderá fornecer nenhuma dica.
Ao a variante fornecer dicas de busca, é
oferecido ao cliente eShop um texto de ajuda sobre como modificar o seu
solicitação de pesquisa para melhores resultados.
Apenas uma das duas
variantes pode ser escolhida.
6 Abordagens
6.1 PLUSS
A abordagem PLUSS (Eriksson, J. Borstler, 2005), propõe uma abordagem para o
gerenciamento do comportamento em casos de uso. Está abordagem também apresenta
meios mais eficientes para rastear variantes em caso de uso, e também para se gerar
modelos de caso de uso específicos de um produto de acordo com modelos de caso de
uso de uma família de produtos de software.
O PLUSS é baseado na abordagem FeatuRSEB (Griss et al, 1998). Segundo (Griss et
al, 1998) os diagramas de caso de uso da UML são ineficientes para realizar a análise de
domínio em LPS e argumenta que o Feature Model (Kang et al, 1990) pode ser usado
como um modelo de alto nível para visualização da LPS.
A abordagem PLUSS propõe modificações no feature model proposto pela abordagem
FODA, pois argumenta que a mesma não define mecanismos para especificar o
relacionamento do tipo “at-least-one-out-of many” (Fey et al, 2002).
Para resolver a lacuna apresentado anteriormente, a abordagem PLUSS propõe o
relacionamento “Multiple Adaptor”, nesse relacionamento ele consegue representar o
relacionamento “at-least-one-out-of many” e também representar a falta de
relacionamento. A abordagem ainda propõe que as features alternativas sejam
renomeadas para “Single Adaptor”. Os relacionamentos foram nomeados segundo o
esquema de nomeação apresentado em (Mannion et al, 2000).
O feature model de acordo com a abordagem PLUSS é apresentado na figura 4.
16
Figura 4. Feature Model da Abordagem PLUSS (Eriksson et al, 2005).
6.1.1 Modelagem de Caso de Uso
Para realizar a modelagem de caso de uso PLUSS propõe que seja utilizado o “Black
Box Flow of Events” (Eriksson et al, 2004). A utilização dessa descrição advém que ela
obriga os analistas sempre pensar sobre interfaces desde campos separados existentes
para descrever ações do ator e do sistema. E também por que fornece um forte
mecanismo para relacionar requisitos não funcionais a casos de uso usando o "Blackbox
Budgeted Requirements".. Na figura 5 é apresentado o “Black Box Flow of Events”.
Figura 5. (a) Blackbox flow of events usado para descrever cenários de uso; (b) Whitebox flow of
events usa do para descrever realização de caso de uso.
A abordagem PLUSS propõe que seja mantido um comum modelo de caso de uso
completo para a família inteira de produtos. Asssim sendo necessário controlar a
variabilidade no modelo de caso de uso, para ter este controle foram identificados
quatro tipo de variabilidade que podem ocorrer em um modelo.
1. Primeiro tipo variabilidade diz respeito do caso de uso como todo que pode
variar entre sistemas construídos dentro de uma família de produtos.
Modelamos isso relativo de um ou mais casos de uso com uma característica de
qualquer tipo no modelo de recurso.
17
2. O segundo tipo de variabilidade que se refere ao conjunto de cenários de casos
de uso inclusos dentro de cada caso de uso. Modelamos este relacionando um
ou mais cenários com uma característica de qualquer tipo no modelo de recurso.
3. O terceiro tipo que diz respeito ao conjunto de etapas incluídas em cada caso de
cenário de uso. Modelamos este relacionando etapas de cenário com
características de qualquer tipo no modelo de features.
4. O quarto tipo de variabilidadese se refere aos aspectos transversais
que pode afetar vários casos de uso em vários níveis. Aspectos transversais são
modelados como parâmetros de casos de uso em PLUSS, estes parâmetros
devem
estar
relacionados
a
um
conjunto
de
simples
adaptador contido no modelo de recurso.
Em PLUSS é extendido o meta modelo proposto por (Eriksson et al, 2004), esta
extensão propõe a integração de fatures, caso de uso e realização de caso de uso. O novo
meta modelo é apresentada na figura 6.
Figura 6. Meta Modelo de PLUSS
Para descrever os passos de um caso de uso, a notação PLUSS propõe algumas
modificações em relação da descrição da realização de casos de uso segundo a UML.
Assim como a UML a abordagem PLUSS identifica cada passo do caso de uso com um
número. A notação de PLUSS são as seguintes:
 Passo obrigarório: um passo é identificado por um número, como acontece na
notação original.
 Passos alternativos mutuamente exclusivos: são identificados com o mesmo
número. Estes passos devem estar relacionados com um conjunto de features
18
que se relacionam como “single adaptor”. A “feature pai” deste “single
adaptor” deve ser uma feature obrigatória.
 Passos alternativos: são identificados com o mesmo número seguido de uma
letra. Estes passos devem estar relacionados com um conjunto de features
“multiple adaptor” e estas features devem ser filhas de uma feature opcional no
feature model.
 Passo opcional: é identificado por um número dentro de parêntesis;
 Passos opcional do qual ao menos um deve ser selecionado: esses passos são
identificados com o mesmo número dentro de parênteses seguido de uma letra.
Essas etapas devem ser relacionados a um conjunto de “multiple adapter” e
possui uma feature pai opcional no feature model.
 Passo opcional de um conjunto de passos opcionais: esses passos são
identificados com um mesmo número entre parentese, igual a identificação de
um passo opcional. Esses passos se referem a um single adaptor.
Além de identificação para os passos do caso de uso, PLUSS ainda utiliza parâmetros
de caso de uso. Esse parâmetros introduzidos em RSEB(Jacobson et al, 1997) e em
(Mannion, 2000) foi apresentado uma distinção em parâmetros locais e globais, os quais
são utilizados nesta abordagem. Sendo que o símbolo „$‟ é utilizado para representar
um parâmetro local e o símbolo „@‟ é utilizado para representar um parâmetro global.
Tanto os parâmetros quanto as notações proposta na abordagem são demonstrado na
figura 7.
Figura 7. Template de documentação com o conceitos de pluss
19
6.1.2 Instanciação de produto
A inserção de uma nova feature no modelo de feature é realizada através da análise do
impacto da inserção do impacto da mesma no modelo de feature visto que o modelo é
único para o sistema como um todo.
Tendo em vista que o modelo de feature é único para a família inteira, para instanciar
um novo produto é apenas escolher as variantes através do modelo de feature.
Após a aplicação do filtro são gerados três documentos. Um Use Case Survey, onde
serão incluídos todos os casos de uso do produto e os relatórios Use Case Specifications
e Use Case Realizations para os casos de uso incluídos no Use Case Survey.
6.1.3 Exemplo
Para exemplificar a utilização desta abordagem, na tabela 1 é apresentada a
especificação do cenário Buy Products.
Id
1(a)
User Action
Select the checkout option. [ShoppingCart]
1(b)
Select the buy product option. [not
ShoppingCart]
2(a)
2(b)
3
Select the confirm option. [Bonus]
Select the confirm option. [not Bonus]
Fill in the requested information and select
the proceed option.
Select the $Shipping-Method$, fill in the
destination address and select the proceed
option.
Confirm the purchase.
4
5
6
System Response
Present the items in the shopping cart and the
amount to be paid. The user can remove items
from shopping cart.
Present the selected product. The user can
change the quantity of items that he wants to
buy. Calculate and show the amount to be paid.
Request bonus and payment information.
Request payment information.
Request the shipping method and address.
Calculate the shipping costs.
Execute the order and send a request to the
Delivery System in order
to dispatch the products.
Register the user preferences.
Select the close session option. [Update User
Preferences]
Tabela 1. Especificação PLUSS do cenário Buy Products
Tendo em vista o cenário apresentado anteriormente, nota-se que os passos 1(a) e
1(b) são passo alternativos mutuamente exclusivos, sendo assim os mesmo jamais
poderão ser executado ao mesmo tempo. Percebe-se que o passo 1(a) apenas será
incluso caso a feature ShoppingCart for selecionadas, caso contrario o passo 1(b) será
selecionado, pois esse exige que a feature ShoppingCart não seja selecionada. De
maneira semelhante ocorre com os passos 2(a) e 2(b), são passos alternativos
20
mutuamente exclusivos, sendo que 2(a) só estará presente caso a feature Bonus for
selecionada e caso contrario o passo 2(b) será selecionado.
Os passos 3, 4 e 5 são anotados como obrigatórios, assim necessariamente irão estar
presente em todos os produtos. O passo 6 é representado por (6) indicando que este
passo é opcional, assim podendo estar presente em alguns produtos e outros não.
6.2 PLUC
A abordagem PLUC (Product Line Use Cases) (Bertolino, 2006) é uma extensão do
caso de uso da UML, esta extensão possibilita inserir variabilidade em casos de uso. A
presente abordagem é baseada na notação apresentada em (Cockburn,2001) a qual tem
por objetivo expressar requisitos em linha de produto, sendo que a mesma adiciona
variabilidade, assim possibilitando representar pontos de variação e variantes.
6.2.1 Modelagem de Caso de Uso
Como explicado anteriormente a notação de descrição de caso de uso utilizada na
presente abordagem, será a notação que é utilizada em (Cockburn,2001) a qual é
apresentada na f igura 8.
Figura 8. Notação de descrição de caso de uso proposto por (Cockburn, 2001)
21
Esta notação de descrição de caso de uso utiliza uma descrição textual com várias
informações. O fluxo principal do cenário de caso de uso é documentado no campo
“Description”, já o fluxo alternativo do cenário é documentado no campo “Extensions”,
ou seja, nesse campo são descritas as variações do cenário.
A adição de variabilidade ao comportamento do caso de uso é alcançada através da
utilização de tags, as quais indicam as partes dos requisitos que podem sofre variação.
Essa extensão é chamado de PLUC, e as tags que são instanciadas são chamadas de
Caso de Uso do Produto (PUC). As tags podem ser de três tipo:
 Alternativa: diz a respeito sobre a possibilidade de escolher uma em um grupo
de features, a escolha de uma feature está condicionada com a realização de uma
condição;
 Paramétrica: neste tipo de tag, a instanciação de um produto está diretamente
ligada com o valor atual de um parâmetro de um requisito de produto especifico.
 Opcional: a escolha de uma feature pode ocorrer ou não independentemente de
um conjunto de features.
6.2.3 Exemplo
Para exemplificar a utilização desta abordagem, na figura 9 é apresentada a
especificação do cenário Buy Products. Neste exemplo será apenas apresentado o
cenário principal e os pontos de variação.
No campo Description são apresentados os passos do cenário principal com os pontos
de variação e no campo Sub Variants são apresentados os pontos de variações e as
condições de suas escolhas. Por exemplo, quando o produto P1 for gerado, o ponto
VP1 será definido como checkout, pois na seção Sub Variants, esta explicitado a
clausula condicional aonde diz que se o produto dor P1 a feature escolhida será
checkout.
22
Figura 9. Cenário Buy Products
6.3 MSVCM
A abordagem Modeling Scenario Variability as Crosscutting Mechanisms (MSVCM)
(Bonifácio, 2010), é uma abordagem de especificação de cenários usando descrição de
cenários textuais.
Está abordagem basicamente é preocupada na especificação de
cenários com foco na separação de interesses através da utilização de técnicas de
orientação a aspectos (Filman et al, 2004). Também melhora a separação de interesses
entre a gestão da variabilidade e especificações de cenários.
Esta abordagem utiliza os seguintes artefatos: Casos de uso, Modelo de Features
(Feature Model – FM), Configuração do produto (Product Configuration – PC),
Configuração de Conhecimento (Configuration Knowledge – CK) e também
Configuração do Produto (Product Configuration).
Esta abordagem alcança os seus objetivos através do processo de combinação
(weaving process) dos artefatos citados anteriormente, esta combinação é baseada no
23
trabalho apresentado em (Masuhara et al, 2003). O weaving process para esta
abordagem foi desenvolvido na linguagem de programação Haskell, o mesmo também é
apresentado na figura abaixo.
Figura 10. Representação Waving Process (Bonifácio, 2010) .
A seguir será apresentado cada um de seus artefatos.
6.3.1 Feature Model
Esta abordagem utiliza o feature model para verificar se a configuração de um dado
produto é valida tendo em vista a linha de produto. Também é utilizado para verificar se
todas as restrições são satisfeitas.
Foi implementada uma função para realizar as verificações citadas acima. Essa função
de verificação toma como entrada o FM e o PC, verificando se o produto especificado
no PC esta de acordo com as restrições expressa no FM.
6.3.2 Modelo de Caso de uso
Neste artefato são descritos os comportamentos esperados pelos membros da SLP.
Um cenário pode ser de diferentes formas, o mesmo pode ser opcional, pode possuir
parâmetros, e até mesmo pode alterar (advice) o comportamento de outros cenários.
Segundo (Bonifácio, 2010), os cenários são usados para detalhar a especificação comum
de um recurso e os advices são utilizados para documentar passos alternativos e
opcionais ou que são dispersos entre as especificações.
Um cenário opcional é usado para representar cenários que estão presentes em
alguns membros da família e não estão presentes em outros. Esta forma de cenário esta
intimamente relacionada com a variabilidade de função (Bonifácio,2010)( Bachmann,
Bass, 2001). Um cenário parametrizado diz a respeito à variabilidade expressa em
detalhes. Esta técnica é relacionada com a fonte de variabilidade chamada variabilidade
24
de dado (Bonifácio, 2010). Já os advices podem se utilizados para modularizarem os
passo opcionais ou alternativos que estão relacionados com a especificação de um
cenário em comum.
A utilização de parâmetros ocorre da seguinte forma <nomeparamentro>. Sendo que o
este parametro permite o reuso do cenário para diferentes configurações. O
relacionamento entre parâmentro e features da LPS são indicados através do CK. Tendo
em vista o CK da LPS que é apresentado na tabela 4, percebe-se que o parâmetro SM é
relacionado com a feature Shipping Method.
Tendo em vista o cenário SC01, apresentado na tabela 2 e o CK, pode-se notar que o
através da utilização do parâmetro <SM> que o cenário Proceed to Purchase pode ser
selecionado para diferentes configurações da feature Shipping Method.
Id: SC01
Description: Proceed to purchase
Id
User Action
System Response
P1
Fill in the requested information and select
the proceed option.
Request the shipping method
and address.
P2
Select one of the available shipping methods
(<SM>), fill in the destination address and
proceed.
Confirm the purchase.
Calculate the shipping costs.
P3
Execute the order and send a request to the
Delivery System to dispatch the products.
[CustomerPreferences]
Tabela 2. Cenário Proceed to purchase
Ainda tem a possibilidade de ter a anotação [nomeparamentro], esta indica que a
este parametro está relacionado um advice. A sua utilização irá depender se o mesmo é
chamado nos campos Before ou After.
Tendo em vista a anotação [CustomerPreferences] na tag After presente na advice
ADV03 (tabela 3), indica que esse advice será executado toda vez que ser encontrado a
anotação [CustomerPreferences] em algum passo de algum cenário, ou seja o advice
ADV03 será executado toda vez que P3 do cenário Proceed to pucharse for executado.
Id: ADV03
Description: Register user preferences.
After: [CustomerPreferences]
ID
R1
User Action
-
System Response
Update the preferences based on the search results or
purchased items.
Tabela 3. Representação do Advice ADV03
25
6.3.3 Configuration Knowledge (CK)
O Configuration Knowledge é responsável por associar as expressões de features a
tarefas. Por expressão de feature entenda-se um conjunto de restrições que deve ser
satisfeita, por exemplo, para expressão (feature1 and not feature2) ser satisfeita,
necessariamente o produto gerado deverá possuir a feature1 e não possuir a feature2. O
CK é o artefato utilizado para guiar a instanciação dos produtos da linha de produto.
Na tabela 4 é apresentado um exemplo de um Configuration Knowledge. A seguir
será explicado o CK aqui apresentado.
Feature Expression
EShop
not (Shopping Cart and Bonus)
(Shopping Cart and Bonus)
Update User Preferences
Shipping Method

Tasks
select scenario SC01
select scenario SC02
evaluate advice ADV01
evaluate advice ADV02
evaluate advice ADV03
bind SM to Shipping Method
Tabela 4. CK do eShop
Toda vez que a feature eShop for selecionada obrigatoriamente os cenários
SC01 e SC02, deveram ser selecionados.

O advice ADV01 será utilizado caso as features Shopping Cart and Bonus
não forem selecionadas.

O advice ADV02 será utilizado caso as features Shopping Cart and Bonus
forem selecionadas.

O advice ADV03 será utilizado caso o a feature Update User Preferences
seja selecionada.

Caso a feature Shipping Method seja selecionada, a variável SM será ligada a
feature Shipping Method.
6.3.4 Configuração do Produto
Através da configuração do produto é identificado um membro especifico da linha
de produto. Neste artefato são selecionadas as features desejadas para a configuração de
um determinado produto. Esta configuração obrigatoriamente terá que respeitar as
restrições presentes no feature model. A instanciação de um determinado membro da
LPS procura satisfazer a configuração do produto, se baseando no CK.
26
De acordo com (BONIFÁCIO, 2010) uma maneira realização configuração de um
produto é utilizando um plugin do eclipse que é chamado de Feature Modeling Plugin
(Antkiewicz, 2004). Na figura 11 é apresentando a configuração de dois produtos
utilizando a ferramenta Feature Modeling Plugin.
Figura 11. Configuração do Produto.
O primeiro produto irá possuir as features Ship Method, Economical e Fast. Já o
segundo produto será composto por todas as fatures do primeiro produto com a adição
da features Shopping Cart, Bonus, Update User Preferences.
6.3.5 Exemplo
Para possibilitar um melhor entendimento desta abordagem, será apresentado um
exemplo realizando a modelagem de variabilidade para o cenário Buy Products.
Mesmo esse cenário já ter sido parcialmente modelado no momento em que esta
abordagem foi apresentada, é necessário a apresentação deste exemplo, pois assim o
leitor terá uma visão completa da abordagem.
O cenário Proceed to Purchase é apresentado na tabela 5. Neste cenário pode-se notar
no passo 2 (representado por P2), a existência do parâmetro <SM> indicando que este
cenários pode ser reusado para diferentes configurações da feature Shipping Method. O
relacionamento entre parâmetros e features ocorre através do artefato Configuration
Knowledge (Tabela 4).
Id: SC01
Descrição: Proceed to Purchase
Id
P1
P2
P3
User Action
Fill in the requested information and
select the proceed option
Select one of the available shipping
methods ( <SM> ), fill in the
destination address and proceed.
Confirm the purchase
System Response
Request the shipping method and address
Calculate the shipping costs
Execute the order and send a request to the Delivery
System to dispatch the products. [CustomerPreferences]
Tabela 5. Cenário Proceed to Purchase
27
No passo 3, pode-se perceber a anotação [CustomerPreferences], esta representa
outro ponto de variação deste cenário. Esta anotação é utilizada como ponto de junção
(pointcuts) nos advices definidos nos casos de uso aspectuais. Esta anotação indica que
sempre que a mesma for encontrada, será chamado o advice Register use preferences
(ADV03) apresentado na tabela 8. A ligação entre a anotação e o advice é feita no
campo After do ADV03.
O advice Buy Produtct representado na tabela 6, permite o cliente comprar produtos
de uma loja eletrônica. Este advice introduz o comportamento antes do join point
identificado na cláusula Berfore que esta junto com a tabela, neste caso este advice
introduz o seu comportamento antes de P1 do SC01(Tabela 5).
Id: ADV01
Descrição: Buy a specific product
Before: P1
Id
B1
B2
User Action
Select the buy product option
System Response
Present the selected product. The user can change the
quantity of items he wants to buy. Calculate and show
the amount to be paid.
Select the confirm option.
Request payment information.
Tabela 6. Advice Buy a specific product
O advice Buy Products with Shopping Cart and Bonus (ADV02) representado na
tabela 7, permite a compra de produto que foram adicionados previamente no carrinho
de compras. Este advice é chamado antes do passo P1 caso o produto possua as feature
Shopping Cart e Bonus.
Id: ADV02
Descrição: Buy Products using a Shopping Cart
Before: P1
Id
C1
C2
User Action
Select the checkout option
System Response
Present the items in the shopping cart and the amount
to be paid. The user can remove items from the
shopping cart.
Select the confirm option.
Request bonus and payment information.
Tabela 7. Advice Buy Products using a Shopping Cart
O advice Register User Preferences (ADV03) representado na tabela 8, introduz o seu
comportamento depois da tag [CustomerPreferences] que é inserida no campo After.
Como exposto anteriormente, no contexto deste exemplo este advice será incluído
depois do passo P3 de SC01, pois o mesmo contém esta anotação.
28
Id: ADV03
Descrição: Register User Preferences
After: [CustomerPreferences]
Id
R1
User Action
System Response
Update the preferences based on the search results or
purchased items.
Tabela 8. Advice Register User Preferences
6.4 VML4RE
A Variability Modeling Language for Requirements (VML4RE)(Alférez et al, 2009),
é uma linguagem de composição de fragmentos de modelos de requisitos para
representar a variabilidades de uma SPL. Entre esses modelos estão incluídos diagramas
de casos de uso e seus cenários, esse são representados por diagramas de atividades.
Esta abordagem visa especificar a composição de modelos de requisitos para produtos
específicos de uma SPL através da utilização de um modelo de composição, o qual
contém transformações (ações nomeados) adaptadas para os cenários.
6.4.1 Representação da Variabilidade
Para representar a variabilidade, VML4RE fornece um conjunto especializado de
operadores para referenciar e compor partes dos cenários e modelo de casos de uso.
Diferentemente de outras abordagens não é acrescentadado anotações nos cenários e
também não é utilizados descrições textuais de formato livre, pois a mesma pode se
tornar ambígua.
O cenário principal e as variantes do fluxo principal, são especificados através de
diagramas de atividades. Para uma dada variante é criada um modelo de composição, no
qual é especificado como será a inserção dos passos da variante no diagrama que
representa o cenário principal. O modelo de composição permite a especificação de
transformações (ações) de composição entre os modelos para representar a
variabilidade.
A composição de cenários é uma transformação modelo-modelo, aonde o modelo do
cenário principal é tranformado em um modelo final. A tranformação é realizada através
de inserção dos passos da variante e remoção de elementos do modelo origem. A
transformação é guiada através do modelo de composição.
29
6.4.2 Exemplo
Agora é apresentada a modelagem do cenário Buy Products em VML4RE. O cenário
Buy Products básico é apresentado na figura 12, o cenário será referenciado com SC01,
para facilitar a explicação do mesmo.
Para a apresentação desse exemplo foi escolhido que o fluxo normal contará com os
passos que são executados caso as features ShoppingCart e Bonus não sejam
selecionadas na configuração do produtos. Os passos referente a ShoppingCart e Bonus
e Update User Preferences foram retirados e modelados como uma variante, pois os
mesmo apenas irão ser inseridos no cenário caso a configuração do produto contenha
essaa feature.
Figura 12. Cenário Básico Buy Products
30
Na figura 13 são apresentados os passo da variante que é inserida no cenário
principal caso a feature ShoppingCart seja inserida na configuração do produto, essa
variante será chamada de VRT01. As ações a ser executadas para a inserção da variante
VRT01 no cenário SC01 são apresentadas no modelo de composição apresentado na
figura 14.
Figura 13. Passos da variante VTR01
Na figura 14 é mostrado o modelo de composição, na linha 2 é realizada a
mesclagem entre o cenário e a variante, as refêrencias aos elementos do segundo
argumento (variante VRT01) são copiados para a referência do primeiro argumento
(cenário SC01). Na linha 3 é conectado o elemento inicial ao passo ATV01 da variante
VRT01. Na linha 4 é conectado o passo ATV02 da variante VRT01 ao passo ATV03
do cenário SC01. Na linha 5 são removidos os passos ATV01 e ATV02 do cenário
SC01.
Figura 14. Modelo de Composição ShoppingCart
Na figura 15 são mostrados os passos que são inseridos no cenário SC01 caso a
feature Bonus será inserida na configuração do produto, essa variante será chamada de
VRT02. As ações a ser executadas para a inserção da variante VRT02 no cenário SC01
são apresentadas no modelo de composição apresentado na figura 16.
Figura 15. Passos da variante VRT02
31
Na figura 16 é mostrado o modelo de composição, na linha 2 é realizada a mesclagem
entre o cenário e a variante, as refêrencias aos elementos do segundo argumento
(variante VRT02) são copiados para a referência do primeiro argumento (cenário
SC01). Na linha 3 é conectado o passo ATV01 do cenário SC01 ao passo ATV01 da
variante VRT02. Na linha 4 é conectado o passo ATV02 da variante VRT02 ao passo
ATV05 do cenário SC01. Na linha 5 são removidos os passos ATV03 e ATV04 do
cenário SC01.
Figura 16. Modelo de Composição Bonus
Na figura 17 são mostrados os passos que são inseridos no cenário SC01 caso a
feature Update User Preferences será inserida na configuração do produto, essa variante
será chamada de VRT03. As ações a ser executadas para a inserção da variante VRT03
no cenário SC01 são apresentadas no modelo de composição apresentado na figura 18.
Figura 17. Passos da variante VRT03
Na figura 18 é mostrado o modelo de composição, na linha 2 é realizada a mesclagem
entre o cenário e a variante, as refêrencias aos elementos do segundo argumento
(variante VRT03) são copiados para a referência do primeiro argumento (cenário
SC01). Na linha 3 é conectado o passo ATV09 do cenário SC01 ao passo ATV01 da
variante VRT03. Na linha 4 é conectado o passo ATV02 da variante VRT03 ao passo
final do cenário SC01.
Figura 18. Modelo de Composição Update User Preferences
32
6.5 MODEL TEMPLATE
O Model Templates (MTs)(Czarnecki, Antkiewicz, 2005) tem por objetivo
representar a variabilidade de uma LPS em vários modelos UML relacionados.
Nesta abordagem o elemento principal é o model family o qual é representado pelo
feature model e o pelo model template. Segundo (Czarnecki, Antkiewicz, 2005) o
feature model é utilizado para representar a hierarquia de feature, bem como as suas
restrições e possíveis configurações. Por outro lado, o model template contém a união
de elementos dos modelos em uma configuração valida. Uma instancia valida do
modelo corresponde a extensão de um model family.
O model template é expresso em termos de uma notação objetivo, a qual depende do
diagrama em que se deseja representar a LPS. Por exemplo, caso se deseja representar
LPS em diagramas de atividade, tanto o model template como o model instance devem
ser representados utilizando a notação do diagrama de atividade.
.
Os elementos de um model template irão ser anotados usando a presence conditions
(PCs) e meta-expressions (MEs). Sendo que estas anotações são definidas em termo de
features e atributos de features do feature model, e estes podem ser analisados tendo em
vista o feature configuration. Um PC apenas será habilitado caso as features que o
compõe sejam selecionadas na configuração do produto.
Tendo em vista a utilização do diagrama de atividades, os PCs podem ser
relacionados a elementos como ações, transições fluxos, nós iniciais e finais.
Uma instancia do model family pode ser especificada criando um feature
configuration baseado em um feature model. Um model template pode ser instanciado
automaticamente com base em um feature configuration. O processo de instanciação é
uma transformação modelo-modelo, sendo que a entrada e a saída são expressas em
notação objetivo. Este processo envolve a avaliação PCs e MEs, removendo as
condições falsas para PCs.
Na figura é apresentado o processo de instanciação de um produto com objetivo de
mostrar como o modelo final é composto. O exemplo utilizado para ilustrar esta
abordagem é retirado de (Czamecki, 2005).
O diagrama 19 deste exemplo é apresentado na figura 19(a). Para essa
exemplificação os elementos relevante são WishLists, SendWishList and Registration,
todas essas três features foram anotadas com “PCs”.
Neste exemplo os PCs são
compostos com uma única variável. O PC para a feature WishLists é [create wish list], o
33
PC para a feature SendWishList é [send wish list] e o PC para a feature Registration(na
figura RegisterWithTheStore) é [register].
A Figura 19(b) mostra um exemplo de
modelo de um produto instanciado criado com base na configuração do recurso
a partir da Figura 20.
Como os PCs correspondentes a SendWishList, não está incluído na configuração,
assim o PC fica avaliado como false e os elementos anotados como o mesmo foram
removidos do modelo final que é apresentado 19(b).
Figura 19. Composição de uma Instancia (Czamecki, 2005)
34
Figura 20. Configuração de Produto Retirada de (Czarnecki Antkiewicz, 2005)
6.5.1 Exemplo
Nesta seção será apresentada a modelagem para o cenário Buy Products na
abordagem Model Template, na figura 21 é apresentado a modelagem e a seguir será
discutido alguns conceitos da desta abordagem.
35
Figura 21. Especificação cenário Buy Products em Model Template
Tendo em vista a figura 21, podem-se observar alguns pontos de variação. Caso a
configuração do produto possua a feature ShoppingCart o passo Select the checkout
option e o passo Present the items in the shopping cart and the amount to be paid.
The user can remove items from shopping cart serão executados, caso contrario os
passos Select the buy product option e Present the selected product. The user can
change the quantity of items that he wants to buy. Calculate and show the amount
to be paid serão executados.
Também se pode verificar uma variação de acordo com a feature Bonus, caso essa
feature seja selecionada na configuração do produto os passos Select the confirm
option e Request bonus and payment Information serão executados, caso contrário
os passos Select the confirm option e Request payment information serão
executadas.
Por ultimo notamos a existência de um ultimo ponto de variação que é referente a
feature Update User Preferences, caso essa feature seja selecionada na configuração
do produto o passo Select the close session option e o passo Register the user
preferences serão executados, caso contrário a execução será encerrada.
36
6.6 PLUS
A abordagem PLUS (do inglês, Product Line UML-Based Software Engineering)
(Gomaa, 2004), é um método de desenvolvimento de software para LPS baseado em
UML. Este método cobre todo o processo de desenvolvimento de LPS, tanto a fase de
engenharia de domínio quanto à engenharia de aplicação. Neste trabalho será
apresentada a parte de modelagem de cenário de uso desta abordagem.
Para esta abordagem a modelagem da variabilidade pode ser tratada de duas
maneiras, podem ser modelagem para pequenas variações e ou variações complexas. As
pequenas variações são modeladas escrevendo o ponto de variação no proprio caso de
uso. As variações ditas como complexas são realizadas quando o caso de uso é muito
complexo e uma parte do mesmo é transformada em um novo caso de uso. As
dependências entre os casos de uso podem ser definidas por relacionamentos include e
extend.
6.6.1 Modelagem de Caso de Uso
Como exposto anteriormente, a modelagem de cenários é realizado tanto para
pequenas variações quanto para variação complexa. Neste momento será apresentado
como é realizada a documentação de cenários de pequenas variações.
6.6.1.1 Modelagem para Pequenas Variações
Segundo (Safonov, 2005) pequenas variações são variações que afetam uma ou duas
linha da descrição de caso de uso. O ponto de variação é colocado dentro do caso de
uso, pois caso contrario ficaria com pequenas variações fragmentadas em vários casos
de uso. Os pontos de variação dentro de um caso de uso são usados para especificar a
funcionalidade opcional ou alternativa dentro da linha de produtos. Para este tipo de
variação apenas é indicado a linha em que a variação poderá acontecer. A
documentação para pontos de variações pequenas devem possuir as informações
contidas no template apresentado na figura 22.
37
Figura 22. Template para descrever pontos de variação pequenos
6.6.1.1.1 Modelagem de variante opcional para Pequenas Variações
Na descrição de variante opcional, o comportamento descrito no campo Description
of functionality é inteiramente inserido nos pontos de variação explicitados contidos nas
linhas descritas no campo Line Numbers.
Para exemplificar este tipo de variante será apresentado o exemplo do ponto de
variação com opção de iluminação ao caso de uso Cook Food (apêndice 1). Este ponto
de variação indica se o micro-ondas irá possuir ou não a opção de iluminação, em que a
luz é ligada quando a porta é aberta e desligada quando a porta está fechada. A luz
também é ligada quando o forno começa a cozinhar a comida sendo que ela é desligada
quando o forno acaba de cozinhar. Na figura 23 é apresentado a variante Light, e logo a
seguir será explicado o mesmo.
Figura 23. Documentação da variante Light
Campo Type of functionality indica que a variante é opcional. No campo Line
number(s) é indicado que caso a feature seja inserida na configuração do produto o
comportamento expresso no campo Description of functionality será inserido nos passos
1, 5, 8, 9 do caso de uso.
38
6.6.1.1.2 Modelagem de variante alternativa para Pequenas Variações
Na descrição de variante alternativa, os comportamentos alternativos são descritos no
campo Description of functionality. Pode haver casos em que uma alternativa seja
padrão. Pode haver casos em que uma variação é obrigatória, em outros casos todos os
comportamentos são opcionais.
Para exemplificar a modelagem deste tipo de variante, será apresentada a variante
Display Language, que é responsável por escolher o idioma das mensagens do
microondas que são exibidas ao usuário. Essas mensagens são mensagens de aviso.
Uma vez que o forno deve ser vendido em todo o mundo, é necessário ser capaz de
variar o idioma de apresentação. O idioma padrão é o Inglês, e as outras línguas
possíveis são francês, espanhol, alemão e italiano. Neste caso, o idioma de apresentação
é um ponto de variação. Na figura 24 é apresentada a documentação da variante Display
Language e logo após a mesma será explicada.
Figura 24. Documentação da variante Display Language
No campo Type of functionality indica que a variante é alternativa e obrigatória, ou
seja, deverá ser selecionada no mínimo uma das alternativas de idioma. No campo Line
number(s) indica que o idioma será alterado nas ações do passo 3 e 8. No campo
Description of functionality indica que o idioma padrão é o Inglês e os idiomas
alternativos são o Francês, o Espanhol, o Alemão ou o Italiano.
6.6.1.2 Modelagem para Variações Complexas
Para pontos de variações complexos são modelado utilizando os mecanismos de
relacionamento extends e include.
Primeiramente será apresentada a modelagem
utilizando o mecanismo extends e após será apresentado o mecanismo include.
39
6.6.1.2.1 Modelagem de variação complexa com relacionamento Extend
Um ponto de extensão pode ser utilizado para modelar uma variabilidade opcional.
Um ponto de extensão com vários casos de uso de extensão pode ser usado para
modelar diversas variantes alternativas em que cada caso de uso de extensão especifica
uma alternativa diferente.
Pode haver caso em que há condições, sendo que essas condições são incluidas para
restringir a seleção dos casos de usos, assim um caso de uso de extensão apenas será
selecionado caso a condição seja verdadeira. Caso a condição seja verdadeira a
funcionalidade da extensão é incluida no caso de uso de um dado membro da linha de
produto que satisfaz a condição. A condição de linha de produtos é definida durante a
configuração do membro linha de produtos e não se altera durante a execução.
Condições da linha de produtos para os casos de uso de extensão alternativos
geralmente não são mutuamente exclusivos, pois é possível que um determinado
membro linha de produtos possa oferecer mais de uma alternativa. Se um caso de uso de
extensão é kernel (Gomaa, 2004), ou seja, obrigatório, então não é necessário atribuirlhe uma condição de linha de produtos, porque o mesmo vai estar sempre disponível.
No entanto, se o caso de uso de extensão é um caso de uso opcional ou alternativo, ele
precisa ter uma condição de linha de produtos.
Para melhor apresentar a modelagem com relacionamento extend, será utilizado o
ponto de variação payment que é declarado no caso de uso Check Out Customer da
linha de produto de supermercado apresentado em (Gomaa, 2004). O caso de uso
principal trata de conferir as compras dos clientes. Três casos de uso de extensão podem
lidar com o tipo de pagamento, os quais são: Pay by Cash, Pay by Credit Card e Pay by
Debit Card. Na figura 25 é apresentada a representação do caso de uso Check Out
Customer e suas extensões através do diagrama de caso de uso, sendo que para cada
ligação é apresentada a condição de seleção do comportamento de caso de uso de
extensão. Após será apresentada a documentação do caso de uso e suas extensões.
40
Figura 25. Diagrama de caso de uso de Check Out Customer (Gomaa, 2004)
Na figura 26 é apresentada a descrição do caso de uso Check Out Customer. Para esse
caso de uso a variabilidade é inserida na linha 6, nesta linha o parâmetro <payment>
indica que neste local a variante poderá ser inserida, neste caso uma forma de
pagamento.
Figura 26. Documentação do caso de uso Check Out Customer
Na figura 27 é apresentada a documentação do caso de uso da extensão Pay by Cash,
esse caso de uso será executado caso a condição [cash payment] seja verdadeira, ou
seja, na configuração de produto a alternativa Pay by Cash tenha sido selecionada para
fazer parte do produto. A condição [cash payment] é expressa no diagrama apresentado
na figura 25 entre o caso de uso Check Out Customer e o caso de uso Pay By Cash.
Caso essa condição seja verdadeira os passos descrito no caso de uso Pay by Cash serão
executados quando a execução do caso de uso Check Out Customer alcançar a linha 6.
41
Figura 27. Extensão Pay by Cash
Na figura 28 é apresentado o caso de uso extensão Pay by Credit Card. De acordo
com o diagrama apresentado na figura 25 esse caso de uso irá ser incluído caso a
condição [credit card payment AND credit card option] seja verdadeira. Esta condição
será verdadeira caso a opção credit card payment tenha sido selecionada na
configuração e o usuário tenha optado por pagar com cartão de crédito.
Figura 28. Extensão Pay by Credit Card
A extensão Pay by Debit Card segue o mesmo estilo da extensão Pay by Credit Card,
em termos de passo da extensão apenas é acrescentado o passo para digitar o PIM do
cartão e a condição de seleção será [debit card payment and debit card option]. Sendo
42
que esta condição será verdadeira caso o a opção debit card payment tenha sido
selecionada na configuração e o usuário tenha optado por pagar com cartão de crédito.
6.6.1.2.2 Modelagem de variação complexa com relacionamento Include
O relacionamento include é usado em situações que os passos do caso de uso se
estendem por vários casos de uso. Assim sendo, um caso de uso obrigatoriamente
dependerá do comportamento de outros caso de uso para conseguir executar o seu
cenário de uso.
O comportamento que é igual para vários caso de uso é inserido em um novo caso de
uso, sendo este novo caso de uso chamado de caso de uso de inclusão. O
comportamento do caso de uso de inclusão é o comportamento que é incluso por outros
casos de uso.
Os casos de uso include podem ser kernel, ou seja, devem ser inclusos toda vez que o
mesmo for chamado ou podem ser opcionais, sendo que estes somente serão
selecionados caso determinada condição seja verdadeira.
Para melhor exemplificar a documentação de variabilidade com o relacionamento
include, será apresentada a documentação de variabilidade do caso de uso Validate PIN
que é extraído de (Gomaa, 2004). Sendo que os casos de uso Withdraw Funds, Query
Account e transfer Funds obrigatoriamente incluíram o caso de uso Validate PIN. O
casos de usos opcional Deposit Funds apenas incluirá o caso de uso Validate PIN caso
a condição [deposit option] seja verdadeira caso e Print Statement apenas incluíra caso
a condição [ministatement option] seja verdadeira . O diagrama de caso de uso Validate
PIN é apresentado na figura 29.
Figura 29. Caso de Uso Validate PIN
43
Na figura 30 o caso de uso Validate PIN é apresenta, o comportamento deste caso de
uso será incluído no comportamento dos casos de uso que o incluem.
Figura 30. Caso de Uso Validate PIN
Na figura 31 é apresentada a documentação do caso de uso Withdraw Funds, como
apresentado na figura 29 este caso de uso inclui o comportamento do caso de uso
Validate PIN. Como apresentado no campo Dependency da figura 31, indica que este
caso de uso tem uma dependência de inclusão com o caso de uso Validate PIN.
No primeiro passo deste caso de uso é realizada a inclusão do caso de uso Validate
PIN, assim sendo quando esse caso de uso for executado, primeiramente será executado
todos os passo do caso de uso Validate PIN para depois executar os passos 2 e 3 do caso
de uso Withdraw Funds.
Figura 31. Caso de uso Withdraw Funds
44
Na figura 32 é apresentada a documentação do caso de uso Deposit Funds. O
campo Dependency indica que este caso de uso irá incluir o comportamento do caso de
uso Deposit Funds. O campo Inclusion condition indica que esse caso de uso Validate
PIN só será incluso caso a condição [deposit option] seja verdadeira. No primeiro
passo deste caso de uso é realizada a inclusão do caso de uso Validate PIN, assim sendo
quando esse caso de uso for executado, primeiramente será executado todos os passo do
caso de uso Validate PIN para depois executar os passos 2 e 3 do caso de uso Deposit
Funds.
Figura 32. Caso de Uso Deposit Funds
6.6.2 Exemplo
Para cada tipo de variação e relacionamento será apresentado um exemplo de
documentação de variabilidade utilizando a linha de produto eShop. Será apresentada a
modelagem para pequenas variações. As modelagens de variações complexas não serão
apresentadas para o escopo do eShop, pois essa linha de produto não suporta estes tipo
de variações.
6.6.2.1 Exemplo de modelagem de pequenas variações
Neste momento será apresentado a modelagem de pequenas variações no contexto de
linha de produto eShop. Primeiramente será apresentada a modelagem de variante
opcional e após é apresentada a modelagem de variante alternativa.
45
6.6.2.1 Exemplo de variante opcional para pequenas variações
Para exemplificar a utilização da modelagem de variante opcional de pequenas
variações será utilizado o cenários de uso Searches goods o qual é apresentado na figura
33.
Figura 33. Cenário searches goods
Para exemplificar a modelagem de variante opcional para pequenas variação será
utilizado o cenário search goods e também será utilizado a variante Show similar
results. Para essa exemplificação foi considerada que a variante Show similar results
como opcional e também foi desconsiderado a variante Provide search hints.
Figura 34. Variante Show similar results
Na figura 34 é apresentado a variante Show similar results, no campo Line number(s)
indicar o comportamento da variante será inserido na linha 3 do cenário Searches
Goods.
6.6.2.2 Exemplo de variantes alternativas para pequenas variações
Para exemplificar variantes alternativas será utilizado o caso de uso Register, o qual é
apresentado na figura 35. Para realizar o registro de um cliente, o mesmo poderá
46
utilizar o formulário simples ou o formulário completo. A documentação dessa variante
é apresentada na figura 36.
Figura 35. Caso de uso Register
Na figura 36 é apresentada a variante Search Options, a qual indica qual tipo de
formulário será disponibilizado para a realização do cadastro do cliente. Caso seja
realizado um registro simples o formulário irá contar com o campo de e-mail address e
postal address. Caso seja realizado um registro completo o formulário irá conter o
campo e-mail address, postal address e também informações bancárias,
Figura 36. Variante Search Options
7 Conclusão
O presente trabalho teve como objetivo apresentar algumas abordagens de
documentação de ponto de variação no contexto de linha de produtos. Para cada
abordagem procurou-se apresentar a motivação da mesma, qual a estratégia utilizada
para documentar a variabilidade. Para cada abordagem foi apresentado um exemplo de
modelagem de variabilidade com a linha de produto eShop.
Antes de apresentar as abordagens de documentação foram apresentados alguns
conceitos básicos que foram utilizados nas abordagens. Primeiramente foi exposta uma
visão geral do desenvolvimento baseado em linha de produto de software, a inserção
deste tópico foi necessária para que o leitor sem conhecimento prévio em LPS adquira
uma visão geral e o leitor que possua uma noção LPS aumente seu conhecimento sobre
47
a mesma. Também foi apresentado o conceito de caso de uso, esse foi necessário, pois
grande parte das abordagens utilizam diagramas de caso de uso e cenários de uso. A
conceituação de orientação a aspectos foi necessária, pois a abordagem MSVCM é uma
abordagem de documentação de variabilidade utiliza os conceitos de programação
orientada a aspectos.
Percebe-se que a variabilidade é documentada das mais diversas formas, algumas
abordagens utilizam descrições textuais Outras abordagens realizam a modelagem de
variabilidade através da utilização de diagramas uml. Todas as abordagens também
propõe como é realizada a derivação de um produto. Com as abordagens apresentadas
neste trabalho é possível realizar uma documentação eficiente de variabilidades em
linha de produto de software.
48
Bibliografia
Alexander I, Maiden N., Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
(John Wiley & Sons, Ltd., 2004).
Alférez, M. Santos, J. Moreira, A, Garcia, A. Kulesza, U, Araújo, J. Amaral, V. Multi-view composition
languagem for software product line requirements. In SLE‟09, 2009. pag 103-122.
Alferez, M. Requirements Engineering Evaluating Approaches for Specifying Software Product Line
Use Scenarios, 2014
Antkiewicz M. and Czarnecki K.. Feature plugin: feature modeling plug-in for eclipse. In OOPSLA
workshop on eclipse technology eXchange, pages 67–72, New York, NY, USA, 2004.
Bachmann, F; Bass, L. Managing variability in software architectures. SIGSOFT Softw. Eng. Notes,
26(3):126–132, 2001.
BECKER, C, GEIHS, K. Quality of Service - Aspects of Distributed Programs. Proceedings of the
Aspect-Oriented Programming Workshop at ICSE‟98. Kyoto (Japão), 1998.
Bergmans L., Commun M.. ACM 44, 51, 2001
Bertolino. A. et al. Product Line Use Cases: Scenario-Based Specification and Testing of Requirements.
In: KAKOLA, T. Software Product Lines: Research Issues in Engineering And Management. 1st Edition.
ed. [S.l.]: Springer-Verlag, 2006. Cap. 11, p. 425-445.
Bonifácio, R. Modeling Software Product Line Variability in Use Case Scenarios – An Approach Based
on Crosscutting Mechanisms. (Tese de Doutorado) Universidade Federal de Pernambuco. Recife - PE,
Brasil. 2010.
Clements P., Northrop L., Software Product Lines: Practices and Patterns. Professional (Addison-Wesley,
2001)
Cockburn, A., Writing Effective Use Cases , Addison-Wesley, Reading, MA 2001
Czarnecki, K., Eisenecker, U.: “Generative Programming: Methods, Tools, and Applications”, AddisonWesley, 2000.
Czarnecki, K., Antkiewicz. M., in Generative Programming and Component Engineering, 4th
International Conference, GPCE 2005, Tallinn, Estonia, September 29 - October 1, 2005, Proceedings,
Lecture Notes in Computer Science, vol. 3676, ed. by R. Gl¨uck,M.R. Lowry (Springer, 2005), Lecture
Notes in Computer Science, vol. 3676, pp. 422–437
Eriksson M., Börstler J., Borg K.: Marrying Features and Use Case for Product Line Requirements
Modeling of Embedded Systems, Proceedings of the Fourth Conference on Software Engineering
Research and Practice in Sweden SERPS‟04, Institute of Technology, UniTryck, Linköping University,
Sweden (2004) 73-82
Eriksson M., Borstler J., and Borg K.. The PLUSS approach - domain modeling with features, use cases
and use case realizations. In SPLC‟ 2005, pages 33–44, Rennes, France, 2005.
Fey D., Fajta R., Boros A.: Feature Modeling: A Meta-model to enhance Usability and Usefulness,
Proceedings of the International Conference on Software Product Lines, Lecture Notes in Computer
Science, Vol. 2371, Springer-Verlag, (2002) 198-216.
Filman R., Elrad T., Clarke S.. Aspect-oriented software development (Addison-Wesley Professional,
2004);
49
Griss M., Favaro J., d‟Alessandro M.: Integrating Feature Modeling with the RSEB, Proceedings of the
Fifth International Conference on Software Reuse, Vancouver, BC, Canada, (1998) 76-85.
GOMAA, H. Designing Software Product Lines with UML: From Use Cases to Pattern-Based
Architectures. Redwood City, CA, USA: Addison Wesley, 2004.
Jacobson I., Griss M., Jonsson P.: Software Reuse – Architecture, Process and Organization for Business
success, Addison-Wesley (1997)
Kang, K., Cohen, S., Hess, J., Novak W., Peterson, A. Feature-oriented domain analysis (FODA)
feasibility study. Technical report, Carnegie-Mellon University Software Engineering Institute, November
1990.
KICZALES G., LAMPING J., MENDHEKAR A., MAEDA C., LOPES C.V., LOINGTIER J..
“Aspect-Oriented Programming. In: European Conference on Object-Oriented Programming (ECOOP”),
06,1997. Finlândia. Anais Springer-Verlag LNCS 1241, 06, 1997.
Krueger. C, Easing the Transition to Software Mass Customization, Revised Papers from the 4th
International Workshop on SoftwareProduct-Family Engineering, p.282-293, October 03-05, 2001.
LOUREIRO J. M., COSTA J. P. C. S. G., FONSECA R. M. S. B., LOUREIRO V. A. N., “Programação
Orientada a Aspecto”. FEUP Universidade do Porto, Porto, Portugal, 2010.
Mannion M., Lewis O., Kaindl H., Montroni G., Wheadon J.: Representing Requirements on Generic
Software in an Application Family Model, Proceedings of the International Conference on Software
Reuse ICSR-6 (2000) 153-196.
Masuhara H. and Kiczales, G.. Modeling crosscuttingin aspect-oriented mechanisms. In ECOOP’ 2003,
pages 2–28, 2003.
Nascimento, L. M. Core Assets Development in Software Product Lines - Towards a Practical Approach
for the Mobile Game Domain. Dissertação (Mestrado), Universidade Federal de Pernambuco, Centro de
Informática, Brasil, 2008.
Larman, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and
Iterative Development. 3rd Edition. ed. [S.l.]: Prentice Hall, 2004.
Parnas, D: On the design and development of program families. IEEE Trans-actions on Software
Engineering, 1976, 2:1–9.
Pereira, T, Uma Abordagem para Recomendação de Módulos para Projetos de Desenvolvimento
Distribuído de Linhas de Produto de Software, Dissertação de Mestrado, Universidade Federal da Paraiba
(UFRN), João Pessoa, 2011.
Pohl K, Linden F. Software Product Line Engineering: Foundations, Principles, and Techniques.
Springer, 2005
Pohl, k. Metzger, A. The eShop Product Line. In SPLC 2006. pp. 584 – 592
SAFONOV R., “Using Aspect-Oriented Programming for Trustwothy Software Development”. WileyInterscience, New Jersey, 2008.
Santander, V. F. A. Integrando Modelagem Organizacional com Modelagem Funcional. (Tese de
Doutorado) Universidade Federal de Pernambuco. Recife - PE, Brasil. 2002.
Silva, J. Agile: Uma abordagem para Geração Automática de Linguagens I*. Dissertação (Mestrado),
Universidade Federal de Pernambuco, Centro de Informática, Brasil, 2011.
50
Torres, M. Avaliação sistemática de abordagens de derivação de produto. Dissertação (Mestrado),
Universidade Federal do Rio Grande do Norte, Departamento de Informática e Matemática Aplicada,
2011.
UML. Unified Modeling Notation, versão 2.4.1, 2011. Disponivel em:<http://www.uml.org/>. Acesso
em: dezembro 2013.
51
Apêndice 1
Na figura 37 é apresentada a documentação do caso de uso Cook Food (Gomma,
2004), este caso de uso será utilizado para apresentar a modelagem de variabilidade da
abordagem PLUS. Nesta representação a sequência do cenário principal é descrito na
seção Description e os passos alternativos são apresentados Alternatives.
Figura 37. Descrição do Caso de Uso Cook Food
52