UNIVERSIDADE FEDERAL DE PERNAMBUCO
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
CENTRO DE INFORMÁTICA
MONOGRAFIA
RASTREABILIDADE DE REQUISITOS EM
LINHAS DE PRODUTO DE SOFTWARE
Autor
Carlos Eduardo Pontual de Lemos Castro
Professor
Jaelson Freire Brelaz de Castro
Recife, julho de 2008
Universidade Federal de Pernambuco
Centro de Informática
CARLOS EDUARDO PONTUAL DE LEMOS CASTRO
Sumário
1. Introdução .............................................................................................. 5
2. Conceitos Estudados .............................................................................. 7
2.1. Linha de Produtos de Software ............................................... 7
2.2. Rastreabilidade em Linhas de Produto de Software ............. 12
3. Abordagens Estudadas ......................................................................... 15
3.1. Modelo de Variabilidade específico para uma aplicação ...... 15
3.1.1. Modelo de Variabilidade Ortogonal ................................ 16
3.1.2. Modelo de Variabilidade de Aplicação ............................ 19
3.2. Framework de Rastreabilidade do AMPLE ............................ 24
3.2.1. Meta-modelo de Rastreabilidade ..................................... 25
3.2.2. Modelo de Referência (reference metamodel)................. 26
3.3. Modelo de Variabilidade Conceitual...................................... 29
3.4. Comparativo .......................................................................... 32
4. Conclusão ............................................................................................. 35
Referências Bibliográficas ........................................................................ 36
2
Índice de Figuras
Figura 1: Artefatos de uma LPS (1) e produtos gerados a partir do reuso
desses artefatos (2, 3 e 4) ..................................................................... 9
Figura 2: Visão geral do desenvolvimento de uma LPS [6]] .......................... 10
Figura 3: Feature-model das possibilidades de configuração de um veículo 11
Figura 4: Rastreando variações em LPS ....................................................... 14
Figura 5: Modelo de variabilidade no topo dos artefatos. ............................ 15
Figura 6: Exemplo do diagrama de variabilidade ortogonal ......................... 17
Figura 7: Notação gráfica do diagrama ortogonal de variabilidade .............. 17
Figura 8: Ambigüidade em requisito .......................................................... 18
Figura 9: Mapeamento das dependências entre os diversos tipos de artefatos
de uma LPS. 1- Diagrama de Variabilidade, 2- Feature Model, 3Diagrama de Casos de Uso, 4- Diagrama de Seqüência, 5- Descrição do
Caso de Uso, 6- Requisitos textuais, 7- Diagrama De Classes, 8Diagrama de Fluxo de dados e 9- Diagrama de Estados ....................... 19
Figura 10: Relação entre DVM e AVM ......................................................... 20
Figura 11: Exemplo de Domain Variability Model com um ponto de variação
(door lock mechanism) e duas variantes (key card, key pad). ............... 20
Figura 12: AVM gerada apenas com reuso de artefatos............................... 21
Figura 13: AVM gerada com uma nova variação e novos requisitos
relacionados ....................................................................................... 22
Figura 14: AVM gerada com reuso parcial da variante key pad.................... 22
Figura 15: Exemplo em que a variação proposta conflita com o DVM
existente ........................................................................................... 24
Figura 16: Meta-modelaso de referência de rastreabilidade ........................ 28
3
Figura 17: Os espaços de problema (problem space) e solução (sulution
speace) ............................................................................................... 30
Figura 18: As três dimensões do desenvolvimento de LPS .......................... 30
Figura 19: Modelo conceitual de variabilidade ............................................ 31
Figura 20: Modelo conceitual de variabilidade para uma LPS de sistemas
bibliotecários...................................................................................... 32
4
1. Introdução
Com o avanço da tecnologia, a necessidade por softwares é cada vez maior.
Entretanto, as exigências do público consumidor de aplicativos também
cresceram muito nos últimos anos. Os clientes, atualmente, não se
contentam mais com softwares de ―caixa‖, que são iguais para todos os
consumidores. Esses consumidores querem aplicações com personalização,
que possam permitir a seleção de todas as funcionalidades presentes, sem
que, para isso, haja aumento dos custos ou atraso da entrega do aplicativo.
Entretanto,
o
custo
de
desenvolvimento
de
uma
aplicação
personalizada é alto, em contraste com o desenvolvimento em massa de um
único sistema, através do qual o custo se dilui pelas diversas cópias iguais
que são vendidas. Esse é o cenário ideal para o conceito de linhas de produto
de
software
(LPS),
que
permite
o
desenvolvimento
de
aplicações
customizadas em massa.
Um importante fator para o sucesso de uma LPS é a rastreabilidade das
variações, pois a rastreabilidade facilita o gerenciamento da LPS, a análise de
impacto de modificações, a evolução da linha e a validação da mesma.
Segundo [12], rastreabilidade é “o link descrevendo o relacionamento ou
dependência entre dois artefatos desenvolvidos durante as várias fases da
engenharia de software”.
Nesse trabalho serão abordadas três soluções de rastreabilidade em
LPS. Apesar de o foco inicial ser a rastreabilidade de requisitos, todas as
soluções aqui introduzidas possibilitam o rastreamento dos diversos tipos de
artefatos gerados durante o desenvolvimento de uma LPS, independente das
fases
do
processo
onde
eles
são
gerados
(requisitos,
arquitetura,
desenvolvimento, testes, etc.).
No capítulo dois são descritos os principais conceitos estudados
durante a composição desse trabalho, Linha de Produtos de Software e
Rastreabilidade em Linhas de Produto de Software. No capítulo três as três
soluções de rastreabilidade em LPS são introduzidas e, após isso, uma
5
pequena comparação entre elas é efetuada. No quarto e último capítulo, são
apresentadas as conclusões obtidas nessa monografia.
6
2. Conceitos Estudados
Nesse capítulo será feita uma abordagem sobre os principais conceitos
envolvidos nesse trabalho. Na seção 2.1 será introduzido o conceito de Linha
de Produtos de Software. Em 2.2 será abordado o conceito principal desse
trabalho, rastreabilidade em linha de produtos de software.
2.1. Linha de Produtos de Software
Com o passar dos anos, o comportamento do público consumidor de
software se modificou bastante. Os clientes de hoje não se contentam mais
com uma única versão de um programa, que seja igual para todos. Eles
querem sistemas personalizados, que tenham apenas um determinado leque
de funcionalidade escolhido por eles, mas não querem que isso comprometa
o custo final e nem o prazo de entrega das aplicações. Além disso, o
mercado de software vem se tornando cada vez mais competitivo, novas
empresas são criadas constantemente e, com elas, novos produtos são
lançados no mercado. Com isso, os desenvolvedores de sistemas são
praticamente
obrigados
a
atenderem
todas
as
necessidades
dos
consumidores, com o menor custo possível, para não perder o cliente.
Entretanto, o desenvolvimento de aplicações personalizadas gera altos
custos, em contraste com o desenvolvimento de aplicações em massa, que
possui um baixo custo por reutilizar a mesma aplicação para diversos
clientes, mas limita as funcionalidades dos sistemas.
É nesse cenário que surge o conceito de linhas (ou famílias) de
produtos de software (LPS), uma abordagem que procura estabelecer um
reuso planejado de componentes (ativos base entre os produtos [1]),
permitindo uma produção em larga escala de produtos customizados para
vários clientes. Essa abordagem, considerado por alguns como um novo
7
paradigma [25], procura aproveitar-se de que poucos sistemas são únicos,
muitas vezes uma mesma empresa produz diversas aplicações similares
pertencentes a um mesmo domínio [2].
Assim, uma LPS nada mais é do que um conjunto de produtos
(software) com várias funcionalidades em comum, mas com variações entre
si. Parnas [3] diz que “em uma LPS o conjunto de propriedades comuns dos
programas é tão grande que é mais vantajoso estudar as propriedades
comuns entre os programas antes de analisar as características individuais
de cada membro”. Já Clements e Northrop [4] definem LPS como “um
conjunto de sistemas de software que compartilham um conjunto gerenciável
comum de características que satisfazem as necessidades específicas de um
segmento de mercado particular e que são desenvolvidas de um conjunto de
ativos base comum, de modo planejado”.
Assim, em uma LPS, é feito um planejamento de que características
comuns serão reutilizadas entre os produtos que serão desenvolvidos
(diferente do que acontece em sistemas únicos, nos quais o reuso não é
planejado, é oportunista, ou ad-hoc, como quando um simples trecho de
código de um produto existente é reutilizado em um novo produto [2]) e, a
partir desse planejamento, são construídos os artefatos comuns (1 na Figura
1) que, posteriormente, são utilizados para gerar os diversos produtos da
linha (2, 3 e 4 na Figura 1). Repare na figura que nenhum dos produtos
gerados é igual ao outro, cada um deles possui variações específicas.
Desse
modo,
temos
uma
grande
diminuição
nos
custos
de
desenvolvimento e manutenção dos programas resultantes da linha, dado
que os artefatos construídos para a LPS são elaborados uma única vez (e não
três vezes, caso três novos produtos fossem desenvolvidos do zero) e a
manutenção deve ser efetuada em um único artefato (novamente, seria
necessário alterar três produtos diferentes caso um erro comum entre as
aplicações fosse detectado, situação que acontece freqüentemente quando é
feito reuso de código de não planejado).
8
O desenvolvimento de uma LPS aborda dois processos diferentes, mas
estritamente
relacionados
[5][6],
Engenharia
de
Domínio
(Domain
Engineering) e Engenharia de Aplicação (Application Engineering). O primeiro
é responsável por definir a estrutura que representará toda a família de
produtos, incluindo os pontos comuns e as variações presentes nos produtos
da linha. Essa estrutura é formada pelos artefatos gerados (ativos base),
como documentos de requisitos, diagramas arquiteturais, diagramas UML [2],
arquivos fonte de código, documentos de teste, etc.
Figura 1: Artefatos de uma LPS (1) e produtos gerados a partir do reuso desses artefatos (2,
3 e 4)
9
No segundo processo, Engenharia de Aplicação, as aplicações da linha
(produtos) são derivadas da LPS gerada no processo anterior. Ou seja, é
nessa etapa que são exploradas as variações da linha, cada produto é ligado
às suas variações, de acordo com suas necessidades. Os artefatos gerados
no primeiro processo são denominados artefatos de domínio (domain
artefacts), enquanto os gerados no último processo são conhecidos como
artefatos de aplicação (application artefacts). Na Figura 2 temos uma visão
geral do processo de desenvolvimento de uma LPS. Repare que, os produtos
gerados (Product models, parte inferior da figura) possuem artefatos que são
variações dos artefatos de domínio.
Figura 2: Visão geral do desenvolvimento de uma LPS [6]
Na literatura, diversos modelos gráficos foram propostos para
representar uma LPS (modelos esses que servem para especificar variações
em linhas de produtos), sendo o modelo de features (feature model, Figura
3) proposto em [7] uma das mais utilizadas. Na Figura 3, a aresta com uma
10
bola sem seu fim indica que uma determinada feature é opcional. Já as
arestas que são separadas por um arco aberto indicam que suas respectivas
features são alternativas. Mais detalhes sobre esse são encontrados em [7].
Diversas são os benefícios trazidos pelo uso de SPL [5], dentre eles
destacam-se:
1. Redução nos custos de desenvolvimento, devido ao reuso de artefatos
de domínio que são construídos uma única vez;
2. Melhora na qualidade dos produtos, pois os artefatos presentes nos
produtos gerados já foram previamente utilizados e testados em
outros produtos, assim, a probabilidade desses artefatos apresentarem
erros é bastante reduzida;
3. Redução no tempo de desenvolvimento, pois apenas os artefatos
específicos de uma determinada aplicação precisam ser desenvolvidos.
Grande parte de um produto gerado é fruto do reuso dos artefatos de
domínio;
4. Redução nos custos de manutenção, pois agora a manutenção é feita
em um único lugar e todos os produtos podem ser gerados novamente
já com os erros corrigidos.
Figura 3: Feature-model das possibilidades de configuração de um veículo [7]
Apesar de tantos benefícios, existem também alguns fatores que
devem ser considerados antes de se optar pelo uso LPS, como o custo e o
11
tempo
total
do
desenvolvimento
do
primeiro
produto,
que
são
consideravelmente maiores do que no desenvolvimento de um sistema único
(estima-se que o custo de uma LPS passa a ser menor do que o custo de
sistemas únicos quando a LPS gera, pelo menos, três produtos [1]).
Assim, é recomendável que uma instituição faça um estudo detalhado
antes de adotar a abordagem de LPS em seu processo de desenvolvimento,
pesando os pontos positivos e negativos, com objetivo de verificar se essa
abordagem pode ou não trazer benefícios para essa determinada empresa.
2.2. Rastreabilidade em Linhas de Produto de
Software
Rastreabilidade é uma característica essencial de um sistema, dado que
ela facilita o gerenciamento do software, a análise de impacto de
modificações, a evolução software e a validação do mesmo.
Gotel e Finkelstein [8] definem rastreabilidade como ―a habilidade de
descrever
e
seguir
o
ciclo
de
vida
de
um
requisito
durante
seu
desenvolvimento e uso, tanto a partir de sua especificação (forward), quanto
de sua especificação para trás (backward), e durante as fases de refinamento
do requisito‖. Ou seja, rastreabilidade é uma importante tarefa no
desenvolvimento de software, dado que ela provê uma ligação entre os
artefatos gerados e a realização das necessidades dos stakeholders do
sistema. [9].
Segundo Berg et.al. [12], o gerenciamento de variabilidade ocupa um
importante papel no sucesso de uma linha de produtos. Existe a necessidade
de uma abordagem de gerenciamento de variabilidade universal, consistente
e escalável, que seja capaz de prover rastreabilidade entre as variações que
ocorrem nos diferentes níveis de abstrações e durante as várias etapas de
desenvolvimento (independente dos tipos de artefatos gerados).
12
Segundo [6], são três os tipos de rastreabilidade que podem ser
encontrados em LPS:
1. Rastreabilidade entre artefatos de domínio ou entre artefatos de
aplicação. Artefatos de uma fase de desenvolvimento durante o processo de
engenharia de domínio são transformados / mapeados em artefatos de outra fase
do mesmo processo (1 e 2 na Figura 2). O mesmo pode ocorrer com artefatos de
aplicação (durante o processo de engenharia de aplicação). Essa é a chamada
rastreabilidade vertical (vertical traceability). Nesse caso, o problema de
rastreabilidade é similar ao encontrado no processo de desenvolvimento de um
único sistema, mas em uma LPS, a rastreabilidade também deve considerar os
modelos utilizados para especificar a variação entre os produtos (ex.: feature
model). Por exemplo, um sistema de controle de acesso pode ter diferentes
mecanismos de verificação de usuário, como senhas, leitores de impressão digital
ou reconhecimento de voz. Entretanto, para cada mecanismo selecionado no
modelo de variação, podemos ter uma alteração na arquitetura do sistema final, e
o mecanismo de rastreabilidade deve ser capaz de associar a seleção dessa
variante no modelo de features com a alteração que vai ocorrer na arquitetura do
produto.
2. Rastreabilidade entre os processos de engenharia de domínio e de
aplicação. Em uma LPS, os artefatos de aplicação de uma determinada fase de
desenvolvimento são obtidos através de artefatos de domínio. Isso acontece
depois decisões que especificam qual o subconjunto de variações que deve ser
incorporado a um produto específico da linha (3, 4 e 5 na Figura 2). Isso implica
que algumas variantes devem ser ligadas a seus respectivos pontos de variações
e outras variantes devem ser descartadas. O gerenciamento de rastreabilidade
em LPS também deve ser capaz de gerenciar esse tipo de relacionamento.
3. Rastreabilidade entre a especificação da variação e realização da
mesma. Muitas abordagens de LPS utilizam modelos específicos, como o feature
model, para representar variações em LPS. Entretanto, os mecanismos que dão
13
suporte a essas variações devem ser incorporados aos modelos de domínio.
Assim, para cada variação deve ser incluído pelo menos um ponto de variação no
modelo de domínio e as possíveis variantes que podem ser ligadas a esses
pontos de variação, representando diferentes alternativas de configuração.
Suponha uma aplicação que proporcione ao cliente a visualização de uma
informação em forma de gráfico (Figura 4). Na hora em que o cliente estiver
tentando acessar os dados, ele deve escolher o tipo de gráfico em que ele deseja
que as informações sejam exibidas. Perceba que o cliente possui três opções de
gráficos disponíveis (lado esquerdo da Figura 4). Essas variações são realizadas
por um mecanismo de plugins, a interface gráfica (GUI) do sistema provê uma
interface (RegisterPlugin) para que os diferentes plugins possam ser adicionados.
Assim, essa interface exerce o papel de ponto de variação, e cada um dos
possíveis tipos de gráficos é um plugin que se registrará na interface caso ele seja
o mecanismo escolhido pelo usuário para exibir as informações na tela. Ou seja,
existem relacionamentos de dependência entre a especificação da existência de
um ponto de variação e como ele é projetado, e entre o conjunto de variantes e a
forma como estas são realizadas. Logo, no contexto de rastreabilidade em LPS,
tais relacionamentos devem ser gerenciáveis.
Figura 4: Rastreando variações em LPS. [6]
Na
próxima
seção
serão
introduzidas
três
abordagens
de
rastreabilidade em LPS. Todas essas abordagens oferecem soluções que
suportam os três tipos de rastreabilidade abordados neste capítulo.
14
3. Abordagens Estudadas
Nesse capítulo, três soluções de rastreabilidade para LPS encontrados na
literatura serão analisadas. Em 3.1 iremos introduzir o modelo de
variabilidade proposto por Pohl [10]. Já em 3.2, será discutido o meta-modelo
de rastreabilidade construído no projeto AMPLE [11]. Finalmente, em 3.3,
veremos a solução proposta por Berg em [12].
Todas as soluções aqui analisadas possuem em comum o fato de
definirem um modelo de variabilidade no topo de ciclo de vida de uma LPS,
englobando os artefatos gerados em todos os estágios da linha, como
podemos ver na figura abaixo (Figura 5).
Figura 5: Modelo de variabilidade no topo dos artefatos. Adaptado de [9]
3.1. Modelo de Variabilidade específico para uma
aplicação
Nessa seção será discutido o modelo proposto em [10]. Em 3.1.1 será
introduzido o Modelo de Variabilidade Ortogonal, que é a base para o
Modelo de Variabilidade de Aplicação (ou Modelo de Variabilidade específico
para uma Aplicação, [10]), descrito em 3.1.2.
15
3.1.1. Modelo de Variabilidade Ortogonal
Em [5] Pohl et al. introduz um Modelo de Variabilidade Ortogonal
(MVO) com o objetivo de representar adequadamente as variações em uma
LPS. Segundo o autor, a documentação de uma variação, para ser
considerada adequada, deve ser capaz de responder as seguintes perguntas:
―O que está variando?‖, ―Por que isso está variando?‖, ―Como isso está
variando (e que artefatos essa variação influencia)?‖ e ―Para quem esta
variação está sendo documentada (usuários finais, externos, ou usuários
internos da empresa)?‖.
O MVO proposto representa as variações em um diagrama de
variabilidade (Variability Diagram) que relaciona suas entidades com as
variações nos artefatos presentes em uma LPS (documentos de requisitos,
diagramas,
arquivos
de
código,
testes,
etc.),
criando,
assim,
uma
dependência entre os artefatos.
Na Figura 6 temos um exemplo do diagrama de variabilidade que
possui um ponto de variação (Door Lock) e duas variantes (Keypad e
Fingerprint Scanner). O arco preto entre as duas variantes significa que elas
são alternativas, e a linha pontilhada significa que ambas são opcionais (uma
linha cheia indica que uma variante é obrigatória, ou mandatória). Cada
variante está ligada diretamente a um caso de uso do diagrama de caso de
uso (lado esquerdo, Figura 6). Assim, caso a variante Keypad seja
selecionada, teremos apenas o caso de uso Unlock Door by Keypad no
diagrama final do produto gerado por essa linha. Caso similar aconteceria
com Unlock Door by Fingerprint caso a outra variante fosse selecionada.
Na Figura 7 temos uma descrição detalhada da notação do diagrama
de variabilidade. ―Ponto de variação‖ (variation point) e ―variante‖ (variant)
são os principais elementos dessa representação gráfica.
16
Figura 6: Exemplo do diagrama de variabilidade ortogonal [5]
Figura 7: Notação gráfica do diagrama ortogonal de variabilidade [5]
O MVO proposto é capaz de resolver diversos problemas até então
presentes em artefatos resultantes do processo de engenharia de requisitos
de uma LPS, como ambigüidade em documentos textuais de requisitos, e a
dificuldade de agrupar as features no feature model. Tome como exemplo o
seguinte trecho de um documento de requisitos: ―O sistema de segurança
deve ser equipado com câmeras preto e branco ou câmeras coloridas
17
capazes de tirarem fotos em modo infravermelho‖. No trecho descrito não
está claro se ambos os tipos de câmera devem ser capazes de tirar fotos em
infravermelho ou se apenas as câmeras coloridas devem tirar fotos em
infravermelho. Suponha que o tipo de câmera escolhido seja um ponto de
variação com duas variantes, câmeras preto e branco ou colorido. Assim, um
possível diagrama de variabilidade utilizando o MVO seria:
Ponto de Variação
O Sistema de segurança deve ser equipado com câmeras ...
Variante
... preto e branco ...
Variante
... ou coloridas ...
... que sejam capazes de tirar fotos em modo infravermelho.
Figura 8: Ambigüidade em requisito. Adaptado de [5]
Como podemos ver na Figura 8, o diagrama de variabilidade gerado elimina a
ambigüidade do sistema, pois agora sabemos que o sistema deve ter
câmeras preto e branco ou coloridas e ambos os modelos devem ser capazes
de tirar fotos em modo infravermelho. Além de permitir a variabilidade em
requisitos textuais, o MVO também permite expressar variabilidades em
diagramas de caso de uso (Figura 6), diagramas de seqüência, cenários de
caso de uso, diagramas de classe, diagramas de fluxo de dados e diagrama
de estados [5].
Para possibilitar a rastreabilidade, podemos representar em um único
diagrama todos os artefatos de requisitos, obtendo assim um grande
mapeamento de dependência entre tais artefatos (Figura 9).
18
Figura 9: Mapeamento das dependências entre os diversos tipos de artefatos de uma LPS. 1Diagrama de Variabilidade, 2- Feature Model, 3- Diagrama de Casos de Uso, 4- Diagrama de
Seqüência, 5- Descrição do Caso de Uso, 6- Requisitos textuais, 7- Diagrama De Classes, 8Diagrama de Fluxo de dados e 9- Diagrama de Estados. Adaptado de [5]
3.1.2. Modelo de Variabilidade de Aplicação
19
Como definido em [10], um modelo de variabilidade de aplicação
(Application Variability Model, AVM) é um modelo em que são documentadas
as variações que necessitam ser feitas no Modelo de Variabilidade do
Domínio (Domain Variability Model, DVM) para que uma aplicação específica
seja gerada (Figura 10). O DVM é um modelo Modelo de Variabilidade
Ortogonal (MVO) que possui apenas os artefatos de domínio de uma LPS, ou
seja, os artefatos resultantes do processo de engenharia de domínio [4], que
são os artefatos planejados para serem reutilizados em uma linha de
produtos (Figura 11).
Figura 10: Relação entre DVM e AVM [10]
Figura 11: Exemplo de Domain Variability Model com um ponto de variação (door lock
mechanism) e duas variantes (key card, key pad). Adaptado de [10].
20
Deste modo, para cada produto de uma LPS, teremos um AVM que será
gerado a partir do DVM dessa linha. A rastreabilidade entre o AVM gerado e
os diferentes artefatos da linha é representada com links de dependência de
artefatos (Artefact Dependencies, Figura 10). Durante a elaboração da AVM
de uma nova aplicação da LPS, podemos nos deparar com as seguintes
situações:
Caso 1 – Reuso total: Nesse caso, o artefato da aplicação (application
artefact) é definido apenas reutilizando o artefato do domínio (domain
artefact). Ou seja, nenhuma adaptação específica para a aplicação é
necessária. Entretanto, é necessário fazer a ligação do ponto de variação
com a(s) variante(s) escolhida para a aplicação. Então, tomando como
base o DVM da Figura 11 e supondo que a aplicação gerada terá apenas a
variante key card, temos que o documento de requisitos da aplicação
agora terá apenas os requisitos R54 e R55 (Figura 12).
Figura 12: AVM gerada apenas com reuso de artefatos [10]
Caso 2 – Sem reuso: Nesse caso, a variação a ser incluída na nova
aplicação não fazia parte dos artefatos de domínio, ou seja, um novo
artefato é desenvolvido para a nova aplicação. Assim, nenhum reuso
acontece e, todos os novos artefatos que são desenvolvidos nas etapas
da LPS por causa dessa variação inserida devem ser ligados na AVM, para
possibilitar o rastreamento da nova variação. Tomando novamente o
exemplo do mecanismo de tranca das portas, a seguinte AVM seria
21
obtida caso uma nova variação, finger print, fosse desenvolvida
especificamente para o novo produto que está sendo gerado (repare nos
novos requisitos de aplicação, R 84 e R 85, fragmentos novos que foram
criados decorrentes da nova variação):
Figura 13: AVM gerada com uma nova variação e novos requisitos relacionados [10]
Caso 3 – Reuso parcial: Nesse caso, o artefato da nova aplicação pode
ser parcialmente definido reutilizando um artefato de domínio, ou seja,
artefatos de domínio podem ser reutilizados, mas precisam de algumas
modificações específicas para atender aos requisitos da aplicação que
está sendo gerada. Por exemplo, suponha que a variante do sistema de
tranca de portas utilizada seja a key pad, mas o cliente impõe uma nova
restrição no tamanho da senha que o usuário deve informar. Nesse caso,
o AVM gerado e os requisitos a serem incluídos na aplicação podem ser
visualizados da seguinte maneira:
Figura 14: AVM gerada com reuso parcial da variante key pad [10]
22
Repare na Figura 14 que o requisito R 12, presente na Figura 11, é
removido apenas para a aplicação que está sendo gerada (no caso,
App. A, o que pode ser visto no rótulo ―delete-elem App.A‖) e, em seu
lugar, é inserido um novo requisito, também apenas para a aplicação
que está sendo elaborada, o R 12a (novamente temos o rótulo App.A).
Dessa maneira, é possível rastrearmos a variação que foi modificada e
descobrirmos o que foi modificado. Isso é muito importante, pois, em
outras etapas da LPS, como a de testes, podemos realizar apenas
pequenas modificações em artefatos já existentes, baseando-nos nos
requisitos modificados, ao invés de desenvolver novos artefatos do zero.
Caso 4 – Conflito com o DVM: Essa situação ocorre quando uma
modificação específica da nova aplicação entra em conflito com as
variações já existentes no DVM. Esse conflito precisa ser resolvido para
que o AVM gerado esteja correto. Considerando novamente o exemplo da
Figura 11, suponha que um cliente deseje um sistema em que seja
possível ter ambos os mecanismos de tranca de portas (i.e., as duas
variantes, key card e key pad). Entretanto, veja que a restrição [1..1] no
DVM permite que apenas uma das variações seja escolhida em um
produto. Assim, é necessário realizar uma modificação nessa restrição no
modelo AVM gerado. Logo, a cardinalidade do ponto de variação door
lock mechanism deve ser alterada para [1..2] no modelo específico da
aplicação (a alteração pode ser identificada pelo símbolo
na Figura 15).
Agora, a aplicação a ser gerada (apenas ela, veja o rótulo App.A) pode ter
ambas as variantes para o variation point em questão.
Nesses quatro casos, podemos perceber que o AVM facilita na
documentação
das
adaptações
específicas
de
uma
dada
aplicação,
centralizando as informações de todos os artefatos que foram alterados
(removidos ou inseridos) por conta das modificações específicas para certos
produtos da linha. Essa centralização nos proporciona uma facilidade maior
23
para validade a consistência do modelo, além de facilitar muito o
entendimento das modificações.
Repare que a idéia do modelo de variabilidade da aplicação é bastante
similar ao MVO [5] que foi discutido na seção anterior. Em [13] é apresentado
outro modelo de variação, no qual as variações são documentadas em um
modelo dedicado (e não nos artefatos de domínio). As vantagens obtidas
utilizando o mecanismo [13] são, essencialmente, as mesmas obtidas
utilizando o modelo AVM.
Entretanto, utilizando AVM, temos que o modelo gerado serve como
um ponto de entrada para navegar (navegação em ambos os sentidos, frente,
forward, e trás, backward) por todos os artefatos (não só os de requisitos,
mas os arquiteturais, os trechos de código, casos de teste, etc.) que foram
afetados por uma modificação específica de um novo produto da linha, coisa
que não ocorre com a abordagem citada em [13].
Figura 15: Exemplo em que a variação proposta conflita com o DVM existente [10]
3.2. Framework de Rastreabilidade do AMPLE
Aspect-oriented Model-driven Product Line Engineering (AMPLE [11]) é
um projeto (consórcio) que tem como membros vários centros de pesquisa
24
em tecnologias espalhados por todo o mundo (Universidade de Lancaster,
Universidade Nova de Lisboa, etc.) e gigantes multinacionais da área de
desenvolvimento de sistemas (Siemens, SAP, etc.). O objetivo desse projeto é
combinar as técnicas de Desenvolvimento de Software Orientado a Aspectos
(Aspect Oriented Software Development, AOSD) e Desenvolvimento Orientado
a Modelos (Model Driven Development, MDD) para possibilitar o controle de
variabilidade em todas as etapas de uma Linha de Produto de Software [6].
Para isso, AMPLE propõe um Framework de Rastreabilidade para LPS.
Entretanto, dentro das limitações do escopo desse trabalho, iremos abordar
nesta seção apenas o desenvolvimento do meta-modelo de Rastreabilidade
para LPS, que é um o elemento central do framework de Rastreabilidade do
AMPLE [6].
3.2.1. Meta-modelo de Rastreabilidade
O meta-modelo de rastreabilidade proposto em Error! Reference
source not found. foi elaborado levando em consideração três fatores:
1. Utilizando como base meta-modelos de rastreabilidade previamente
definidos (em especial o MODELWARE [14]);
2. Analisando o resultado de um survey sobre rastreabilidade em Linhas
de Produtos de Software com foco em Orientação a Aspectos realizado
em outra etapa do AMPLE [9];
3. De acordo com as necessidades de rastreabilidade e os requisitos de
vários projetos realizados nas instituições que compõe o consórcio
AMPLE (diversos cenários fornecidos pelos parceiros do projeto foram
analisados).
O desenvolvimento desse modelo foi aconteceu em duas etapas. Na
etapa inicial, foi desenvolvido um meta-modelo de referência (reference
25
metamodel), com o objetivo de suportar a definição de diversos modelos
específicos de rastreabilidade, um para cada um dos projetos analisados
(terceiro fator descrito acima). Na segunda fase ocorreu o desenvolvimento
de um meta-modelo de rastreabilidade específico (core metamodel), baseado
nas necessidades do projeto AMPLE.
Esse
modelo
de
referencia
permite
a
definição
de
links
de
rastreabilidade com múltiplas ―fontes‖ e ―destinos‖ e, permite também,
definir os tipos desses links, definir o tipo dos artefatos que serão
interligados, e associar informações adicionais de contexto a esses links.
Além disso, com ele podemos descrever e ―seguir‖ toda a vida dos diversos
artefatos de uma LPS (documento de requisitos, classes, etc.) em ambos os
sentidos
(forward
e
backward) durante
cada
fase
do processo de
desenvolvimento da linha.
Como o meta-modelo específico do projeto AMPLE ainda não está
completo, iremos abordar nesse trabalho (na próxima subseção) apenas o
modelo de referência proposto no AMPLE.
3.2.2. Modelo de Referência (reference metamodel)
A especificação de um meta-modelo de rastreabilidade requer algumas
decisões prévias, como a definição dos artefatos que devem ser rastreados
(ex. casos de uso, feature models, componentes, etc.) e o tipo de
relacionamento entre artefatos (ex. dependência, influência, etc.) que o
modelo deve suportar. Entretanto, esses artefatos e tipos de relacionamentos
podem variar para cada tipo de projeto.
Desse modo, o meta-modelo desenvolvido possui uma estrutura que
facilita a especificação de artefatos e relacionamento entre artefatos que irão
ser rastreados. O fato dos meta-modelos de rastreabilidade presentes em
cada um dos projetos analisados não serem completamente disjuntos (i.e.,
eles possuem vários elementos comuns) permite a definição de um meta26
modelo de referência que pode ser, futuramente, estendido para gerar
modelos específicos.
Para ser compatível com as diversas ferramentas em desenvolvimento
nas outras etapas do projeto AMPLE, o meta-modelo gerado deve ser
facilmente
implementado
em
Ecore/EMF
[15].
Na
literatura,
muitas
representações genéricas de modelos de rastreabilidade foram encontradas
[6]. Por isso, foi decidido que o meta-modelo de referência seria gerado a
partir da adaptação de meta-modelos de rastreabilidade já existentes, em
especial o modelo gerado no projeto MODELWARE, que é implementado em
Ecore e tem foco na rastreabilidade do desenvolvimento orientado a
modelos. Mais detalhes sobre MODELWARE podem ser encontrados em
[14][16].
O meta-modelo de referência foi projetado em MOF 2.0 [17], pois MOF
tem a característica de ser facilmente portado para Ecore (exigência de
compatibilidade com ferramentas). As meta-classes que compõe o metamodelo de referência podem ser vistas na Figura 16.
Basicamente, o meta-modelo de referência de rastreabilidade define a
noção de TraceModel (―modelo rastreável"), que é o elemento central desse
modelo. O TraceModel armazena todas as informações de rastreabilidade em
conjuntos de mapeamento de conjuntos de artefatos origem em conjuntos
de artefatos destinos (ou seja, dois conjuntos de artefatos rastreáveis). Um
TraceableArtefact (―artefato rastreável‖) pode fazer o papel tanto de origem
como de destino do mapeamento (ex. um artefato de arquitetura pode ser o
destino de um mapeamento com origem em artefatos de requisitos, e, ao
mesmo tempo, pode ser a origem de um mapeamento cujo destino são
artefatos de implementação).
Além de armazenar artefatos rastreáveis, o TraceModel armazena
também
TraceableHyperLinks
(super-links
rastreáveis).
Geralmente, os
TraceableArtefact são apenas links para artefatos existentes em algum tipo
de arquivo ou modelo. Nesses casos, esses artefatos rastreáveis são
instâncias de TraceableArtefactsRef (referências para artefatos rastreáveis),
27
meta-classe que armazena uma URI com o endereço real do devido artefato
(ex. um documento de texto, um modelo UML, etc.) e um id que identifica
um local específico nesse artefato (ex. uma linha no documento de texto, o
nome ou o id de um modelo dentro de um diagrama UML).
Os TraceableHyperLinks representam, explicitamente, o rastreamento
entre o relacionamento de um conjunto de artefatos origem e um conjunto
de artefatos destino. Isso permite que o modelo de rastreabilidade seja
visualizado como um conjunto de hipergrafos diretos e bi-partite, com
suporte a anotações, da forma G = (V1 + V2,E), V1 é o conjunto de artefatos
origem, V2 é o conjunto de artefatos destino e E é o conjunto de arcos com
anotações que saem de V1 e chegam em V2. Para permitir um maior nível de
expressividade de rastreabilidade nos relacionamentos, os super-links podem
ser decompostos em conjuntos de TraceLinks (links rastreáveis), que podem
representar um relacionamento específico (ex.: dependência) entre um
artefato origem e um destino.
Figura 16: Meta-modelo de referência de rastreabilidade [6]
28
Mais detalhes sobre as meta-classes do meta-modelo de referência, a
descrição completa de cada elemento da Figura 16, e os detalhes de como
esse modelo foi implementado em Ecore podem ser encontrados em [6].
3.3. Modelo de Variabilidade Conceitual
Segundo Berg et. al. [12], o gerenciamento de variabilidade tem um
papel fundamental no sucesso da engenharia de LPS. Assim, existe a
necessidade de uma abordagem de gerenciamento de variabilidade que seja
universal, consistente, escalável, permita a rastreabilidade entre as variações
que ocorrem nos diversos tipos de artefatos presentes em uma LPS, e que
forneça um mecanismo que permita a visualização dessas variações.
Assim, [12] define um modelo conceitual de variabilidade que suporta
a rastreabilidade das variações ocorrentes nos diversos níveis de abstração
(fases de requisitos, análise, arquitetura, etc.), entre os vários tipos de
artefatos presentes em uma LPS (documento de requisitos, arquivo de código
fonte, etc.). A solução proposta utiliza um modelo de três dimensões para
possibilitar o rastreamento em uma LPS, são elas:
1. Nível de abstração: No projeto de uma aplicação existe uma grande
diferença entre os níveis de abstração nas diversas fases de
desenvolvimento (requisitos, análise, arquitetura, etc.). O mesmo
ocorre em uma LPS, e os diferentes níveis de abstração são
representados em uma dimensão do modelo proposto.
2. Espaço de Desenvolvimento: Os termos espaço de problema (problem
space) e espaço de solução (solution space) foram introduzidos por
Czarbecki e Eisenecker em [18]. Os dois espaços juntos representam
todas as fases do desenvolvimento de uma LPS (Figura 17).
29
3. Variabilidade: Essa é a grande novidade desse modelo, pois em [12] o
autor considera que o desenvolvimento de uma única aplicação
acontece nas dimensões ―Espaço de desenvolvimento x Nível de
Abstração‖. Entretanto, tratando-se de uma LPS, uma nova dimensão
deve ser considerada, a variabilidade, que captura, explicitamente, as
informações de variação entre os produtos da linha.
Figura 17: Os espaços de problema (problem space) e solução (sulution speace) [12]
Na Figura 18 temos um exemplo de como são distribuídas as três
dimensões no modelo proposto.
Figura 18: As três dimensões do desenvolvimento de LPS [12]
Apesar de o autor relatar que uma solução unificada de gerenciamento
de variabilidade deve ser consistente, escalável, prover o rastreamento entre
as variações e permitir uma visualização das variações, o modelo introduzido
30
por Berg garante apenas a rastreabilidade e a visualização das variações, pois
nenhum teste de consistência e escalabilidade foi efetuado.
O modelo conceitual de variabilidade proposto é dito unificado pelo
fato de todas as variações, independente do artefato onde elas ocorrem, são
mapeadas da mesma maneira na dimensão de variabilidade. As variações nos
diversos artefatos ocorrem nos pontos de variações (i.e. as variantes ligam-se
aos pontos de variações em cada artefato para que uma variação seja, de
fato, realizada), o modelo proposto estrutura e captura os diversos pontos de
variação relacionados a uma única variação (i.e. uma única variação no
modelo de features pode acarretar em vários pontos de variação nos diversos
artefatos) em um único ponto na dimensão de variabilidade.
É importante ressaltar que a solução proposta não representa mais um
nível de abstração no processo de desenvolvimento de uma LPS, mas apenas
especifica uma nova dimensão para levar em conta a variabilidade, que está
presente em todo o processo de desenvolvimento (Figura 19Figura 1). Na
Figura 20 temos um exemplo do modelo conceitual de variabilidade proposto
para uma LPS de sistemas de biblioteca.
Figura 19: Modelo conceitual de variabilidade [12]
31
Figura 20: Modelo conceitual de variabilidade para uma LPS de sistemas bibliotecários [12]
3.4. Comparativo
Como citado na introdução desse capítulo, todas as abordagens aqui
introduzidas possuem um modelo de variabilidade que atua ao longo de todo
o ciclo de vida da LPS (Figura 5). Um ponto importante que deve ser frisado é
o fato de haver uma diferença considerável, com respeito à maturidade, entre
as abordagens citadas nesse trabalho, dado que uma delas já foi bastante
trabalhada e estendida (o modelo de Pohl et. al., proposto em [5] e estendido
em [13] e [10]) e as outras duas foram somente propostas (abordagem de
Berg et. al.) ou ainda estão em desenvolvimento (o framework de
rastreabilidade do projeto AMPLE).
Nessa seção é feito um pequeno comparativo entre as três abordagens
introduzidas
nesse
trabalho,
com
foco
em
quesitos
básicos,
como
escalabilidade, suporte ferramental, e mapeamento e granularidade dos
relacionamentos entre os artefatos.
32
O modelo de variabilidade específico para uma aplicação (ou modelo
de variabilidade de aplicação, AVM, seção 3.1.2) é uma extensão do modelo
ortogonal de variabilidade. (OVM, 3.1.1). O AVM (como o OVM) possibilita o
rastreamento de uma variabilidade em ambos os sentidos, forward e
backward. Além disso, essa solução permite rastrear a variabilidade no nível
de partes de artefatos (ex.: linhas de texto em um documento de requisitos,
casos de uso em um diagrama de casos de uso). Quanto à escalabilidade, em
[5] é mencionado que o OVM é escalável. Entretanto, nada sobre
escalabilidade é dito em relação ao AVM em [10].
O suporte ferramental é o grande problema do modelo de Pohl, dado
que para o OVM existe apenas uma ferramenta para modelar as variações,
mas nenhuma ligação com os devidos artefatos é proporcionada. O mesmo
ocorre com o AVM.
Em [12], nenhum comentário é feito sobre a possibilidade de
rastreamento
(forward
ou
backward)
do
modelo
de
conceitual
de
variabilidade (seção 3.3). O mesmo ocorre quanto à escalabilidade, nada é
comentado no artigo em questão. O modelo de Berg et. al., assim como o de
Pohl, permite rastrear a variabilidade a nível de partes de artefatos. Mas, esse
modelo é apenas conceitual, nenhum uso real dele foi demonstrado em [12].
Assim, nenhum suporte ferramental está disponível essa solução.
O framework de rastreabilidade do projeto AMPLE (seção 3.2) foi
definido com base em um grande survey sobre as técnicas pré-existentes de
rastreabilidade em LPS. Deste modo, tal modelo visa solucionar todos os
problemas existentes na literatura. Pelo fato do AMPLE ainda estar em
andamento, tal framework ainda não está completo. Então, nesse trabalho
abordamos apenas o elemento principal do framework, o meta-modelo de
rastreabilidade.
O meta-modelo em questão permite a rastreabilidade de variações em
partes de artefatos em ambos os sentidos (backward e forward). Além disso,
esse meta-modelo é escalável, dado que ele serve apenas como um modelo
de dados que é manuseado por ferramentas externas (i.e. esse modelo de
33
dados é armazenado em algum banco de dados e manuseado por
ferramentas
específicas).
O
suporte
ferramental
do
framework
de
rastreabilidade ainda não está completo, pois o projeto AMPLE só terminará
em 2009. Entretanto, diversas ferramentas para manuseio do meta-modelo
estão em desenvolvimento.
Na Tabela 1 podemos ver um pequeno resumo do comparativo aqui
efetuado. Quando uma determinada nenhuma informação sobre um critério
de comparação não foi obtida na literatura, o símbolo ―—― foi colocado na
tabela.
Abordagem
Modelo de variabilidade
Tipo de
Nível de
Rastreabilidade
rastreabilidade
forward/backward
parte de artefatos
Escalável
Ferramentas
—
Não (apenas para gerar o
aplicação-específico
Modelo Conceitual de
modelo das variações)
—
parte de artefatos
—
Variabilidade
Framework de
Rastreabilidade do AMPLE
Não (modelo ainda conceitual,
nenhum uso real efetuado)
forward/backward
parte de artefatos
Sim
Sim (porém as ferramentas
estão em desenvolvimento)
Tabela 1: Comparativo entre as abordagens analisadas
É importante ressaltar que nesse trabalho foram analisadas apenas
abordagens que possuem um modelo de variabilidade ao longo de todo o
ciclo de vida da LPS. Assim, um possível trabalho futuro seria fazer uma
comparação incluindo abordagens com rastreabilidade a nível de artefatos
([19][20][21]) e abordagens com rastreabilidade em alta granularidade
([22][23][24]).
Um dos poucos trabalhos relacionados a esse presente na literatura é
um documento do projeto AMPLE [9]. Entretanto, nesse documento o Modelo
de Variabilidade de Aplicação (AVM) não é citado (apenas o Modelo Ortogonal
de Variabilidade – OVM – é abordado). Além disso, por se tratar de um
documento de uma fase inicial do AMPLE, o framework de rastreabilidade
proposto nesse mesmo projeto também não é tratado em [9].
34
4. Conclusão
Os clientes de software estão cada vez mais exigentes. Atualmente, esse
público não se contenta mais com sistemas únicos, que sejam iguais para
todos. Eles querem escolher as funções dos sistemas que estão comprando,
mas não querem que o tempo de entrega e o custo final do produto
aumentem. Essas exigências, aliadas à grande concorrência presente no
mercado de software, formam o cenário ideal para o uso de LPS, que permite
o desenvolvimento de aplicações customizadas em massa.
Um importante fator para o sucesso de uma LPS é a rastreabilidade das
variações, pois ela facilita o gerenciamento da LPS, a análise de impacto de
modificações, a evolução da linha e a validação da mesma.
Nesse
trabalho
foi
feito
um
estudo
de
três
abordagens
de
Rastreabilidade em Linha de Produtos de Software. Todas as abordagens aqui
introduzidas mapeiam a variabilidade em todos os tipos de artefatos
presentes em LPS (requisitos, arquitetura, código, teste, modelo de features,
etc.), além de proporem um modelo de variabilidade que atua durante todo o
ciclo de vida de uma LPS. Além disso, uma pequena comparação entre as
abordagens estudadas é
feita no final do capítulo 3, levando em
consideração quesitos básicos, como escalabilidade, suporte ferramental, e
mapeamento e granularidade dos relacionamentos entre os artefatos.
Como trabalhos futuros, uma analise de abordagens que possuam
rastreabilidade a nível de artefatos e abordagens com rastreabilidade em alta
granularidade pode ser feita e comparada com os resultados desse trabalho,
que abrange apenas abordagens com modelo de variabilidade no topo da
LPS.
35
Referências Bibliográficas
[1]
WEISS, David. LAI, Robert: Software Product-Line Engineering. A Family-
Based Software Development Process. 1. Ed. Boston: Addison-Wesley
Professional, 1999. 448p.
[2]
TEIXEIRA, Leopoldo M.: “Ligo: Uma linha de produto de software para
gerenciamento de igrejas cristãs”, Trabalho de Conclusão de Curso, Recife,
Brasil, 2007.
[3]
PARNAS, David L: On the design and development of program families.
IEEE Trans-actions on Software Engineering, 1976, 2:1–9.
[4]
CLEMENTS, Paul, NORTHROP, Linda: Software Product Lines: Practices
and Patterns. 3. ed. Boston: Addison-Wesley, 2002. 608 p.
[5]
POHL, Klaus, BÖCKLE, Günter, VAN DER LINDEN, Frank: Software
Product Line Engineering: Foundations, Principles, and Techniques. 1. ed.
New York: Springer, 2005. 468 p.
[6]
Projeto AMPLE: Definition of a traceability framework (including the
metamodel and the modelling of processes and artefacts to allow traceability
in
the
presence
of
uncertainty)
for
SPLs.
http://ample.holos.pt/gest_cnt_upload/editor/File/public/Deliverable%20D4.
1.pdf, AMPLE Project, Deliverable D4.1, 2008
[7]
KANG, Kyo. C., COHEN, Sholom. G., HESS, James. A., NOVAK, William E.,
and PETERSON, A. Spencer: Feature-Oriented Domain Analysis (FODA)
Feasibility Study. Technical Repot CMU/SEI-90-TR-21, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, PA, 1990.
[8]
GOTEL, Orlena C. Z., FINKELSTEIN, Anthony C. W.: An Analysis of the
Requirements Traceability Problem, in Proceedings of the International
36
Conference on Requirements Engineering. IEEE Computer Science Press,
1994.
[9]
Projeto AMPLE: State-of-the-art for traceability in software product line
development, with specific focus on aspect traceability in the software
development process. Evaluate the potential benefits of aspect-oriented
programming and model-driven engineering, AMPLE Project, Deliverable
M4.1, 2008
[10]
HALMANS,
Günter,
POHL,
Klaus,
SIKORA,
Ernst:
Documenting
Application-Specific Adaptations in Software Product Line Engineering. CAiSE
2008: 109-123
[11]
Projeto AMPLE: Aspect-Oriented, Model-Driven Product Line Engineering
http://ample.holos.pt/. Acesso em Julho de 2008
[12]
BERG, Kathrin., BISHOP, Judith., and MUTHIG, Dirk: Tracing software
product line variability: from problem to solution space. In Proceedings of the
2005 Annual Research Conference of the South African institute of Computer
Scientists and information Technologists on IT Research in Developing
Countries (White River, South Africa, September 20 - 22, 2005). ACM
International Conference Proceeding Series, vol. 150. South African Institute
for Computer Scientists and Information Technologists, 182-191.
[13]
Bühne, S., Lauenroth, K., Pohl, K.: Modelling Requirements Variability
across Product Lines. In: Atlee, J.M. (ed.) 13th IEEE Intl. Conference on
Requirements Engineering, pp.41–50. IEEE Computer Society, Los Alamitos
(2005)
[14]
Projeto ModelWare: Traceability metamodel and system solution.
http://www.modelwareist.org/index.php?option=com_remository&itemid=79
&func=fileinfo&id=134, ModelWare Project, Deliverable D1.6, 2006.
37
[15]
BUDINSKY, Frank, STEINBERG, Dave, MERKS, Ed, ELLERSICK, Ray, and
GROSE, Timothy J.: Eclipse Modeling Framework. Addison-Wesley, August
2003.
[16]
Projeto ModelWare: http://www.modelwareist.org/. Acesso em: Julho
de 2008.
[17]
OMG.:
Meta
object
facility,
mof
2.0.
http://www.omg.org/spec/mof/2.0/, OMG. Acesso em Julho de 2008.
[18]
CZARNECKI,
Krzysztof,
EISENECKER,
Ulrich
W.:
Generative
programming: methods, tools, and applications, ACM Press/Addison-Wesley
Publishing Co., New York, NY, 2000
[19]
JIRAPANTHONG, Waraporn e ZISMAN, AndreA: “Supporting product line
development through traceability”, In APSEC, pages 506--514. IEEE Computer
Society, 2005.
[20]
KNAUBER, Peter e SCHNEIDER, Johannes: “Tracing Variability from
Implementation to Test Using Aspect-Oriented Programming”. Avaya Labs
Technical Report: ALR-2004-031: International Workshop on Software Product
Line Testing (SPLiT 2004), Co-located with the 3rd International Software
Product Line Conference, SPLC 2004, August 2004, Boston, Massachusetts,
USA.
[21]
MERGEL, Martin, THIEL, Steffen, FERBER, Stefan: “Product Line Asset
Classification and Dependency Specification”. ESAPS project, Consortium-wide
deliverable, 2000.
[22]
ZISMAN, A., SPANOUDAKIS, G., PEREZ-MINANA, E, KRAUSE, P.: “Towards
a Traceability Approach for Product Families Requirements”. 3rd ICSE
Workshop on Software
Product
Lines:
Economics, Architectures, and
Implications. Orlando, USA, 2002.
38
[23]
MOHAN, Kannan e RAMESH, Balasubramaniam: “Managing Variability
with Traceability in Product and Service Families”. In Proceedings of the 35th
Hawaii International Conference on System Sciences, 2002.
[24]
RAMESH,
Balasubramaniam,
TIWANA,
Amrit,
MOHAN,
Kannan:
“Supporting Information Product and Service Families with Traceability”. In
Proceedings of PFE '01: Revised Papers from the 4th International Workshop
on Software Product-Family Engineering, pages 353--363, Springer-Verlag,
2002
[25]
CLEMENTS, Paul: “Software Product Line – A New Paradigm for the New
Century”; CrossTalk, pp. 20-23, February 1999.
39