aplicação de lógica descritiva para validação de ... · aplicação de lógica descritiva para...
TRANSCRIPT
UNIVERSIDADE FEDERAL DE GOIÁS � UFG
CAMPUS CATALÃO � CaC
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO � DCC
Bacharelado em Ciência da Computação
Projeto Final de Curso
Aplicação de Lógica Descritiva para Validação deRequisitos em Linha de Produto de Software
Autor: Fernando Antônio Asevedo Nóbrega
Orientador: Vaston Gonçalves da Costa
Co-orientadora: Luanna Lopes Lobato
Catalão - 2010
Fernando Antônio Asevedo Nóbrega
Aplicação de Lógica Descritiva para Validação de Requisitos em Linha de
Produto de Software
Monogra�a apresentada ao Curso de
Bacharelado em Ciência da Computação da
Universidade Federal de Goiás Campus Catalão
como requisito parcial para obtenção do título de
Bacharel em Ciência da Computação
Área de Concentração: Teoria da Computação
Orientador: Vaston Gonçalves da Costa
Co-orientadora: Luanna Lopes Lobato
Catalão - 2010
Nóbrega, Fernando Antônio Asevedo
Aplicação de Lógica Descritiva para Validação de Requisitos em Linha de
Produto de Software./ Fernando Antônio Asevedo Nóbrega � Catalão �
2010
Número de páginas: 36
Projeto Final de Curso (Bacharelado) Universidade Federal de Goiás, Campus
Catalão, Curso de Bacharelado em Ciência da Computação, 2010.
Palavras-Chave: 1. Representação de Conhecimento. 2. Requisitos Formais. 3.
Linha de Produto de Software. 4. Lógica Descritiva. 5. Validação de Requisitos.
Fernando Antônio Asevedo Nóbrega
Aplicação de Lógica Descritiva para Validação de Requisitos em Linha de
Produto de Software
Monogra�a apresentada e aprovada em de
Pela Banca Examinadora constituída pelos professores.
Vaston Gonçalves da Costa � Presidente da Banca
Luanna Lopes Lobato � Co-orientadora
Liliane do Nascimento Vale
Thiago Jabur Bittar
Dedico está monogra�a a minha família
minha mãe Maria Salete Asevedo Nóbrega
meu pai Francisco das Chagas Nóbrega e meus irmãos
Francisco das Chagas Nóbrega Júnior
e Sidnei Nóbrega de Lima.
Que sempre me apoiaram e incentivaram para que eu alcançasse meus objetivos.
AGRADECIMENTOS
Agradeço primeiramente a Deus, por ter me possibilitado a vida e iluminado meu
caminho, dando-me capacidade para criar meu próprio destino e me enchendo de boas
possibilidades.
Agradeço a minha família, minha mãe Maria Salete Asevedo Nóbrega, meu pai Fran-
cisco das Chagas Nóbrega e meus irmãos Francisco das Chagas Nóbrega Júnior e Sidnei
Nóbrega de Lima, que sempre me apoiaram e foram um recanto de paz nos momentos de
stress e ansiedade durante toda minha graduação.
Meus amigos que compartilharam alegrias e tristezas durante todo a caminhada de
minha graduação e deste trabalho: Adam Moreira, Ana Paula Suzuki, Bleno Leite, Bruno
Nascimento, Diego Je�erson, Faimison Rodrigues, Hugo Sica, Jayme Calixto, Leandro
Fernandes, Leandro Pedrosa, Luiz Gustavo, Márcia Ribeiro, Paulo Henrique, Renato
França, Tiago Batista e Wilkliney Pires. Todos vocês são grandes amigos.
Em especial ao Adam por ter me auxiliado no ensaio antes da minha defesa de PFC, a
Márcia, Hugo, Pedrosa membros do grupo RESEARCH-UFG que durante nossos estudos
me apelidaram carinhosamente de doente kkk (tive que colocar risadas). Agradeço o apoio
e companheirismo de vocês.
Meus amigos também já formados, José Augusto e Rafael Ulhoa, são como irmãos
para mim, me ajudando sempre que possível e sempre compartilhando comigo momentos
engraçados.
Agradeço também a Fernanda Bontempo por em tão pouco tempo me passar conforto
e pegar no meu pé nas horas necessárias.
Não posso deixar de mencionar meu orientador Vaston Gonçalves pela orientação no
trabalho, e conversas incentivadoras, minha co-orientadora Luanna Lopes, pela sua orien-
tação e principalmente por suas revisões. Vocês foram de grande importância para meu
crescimento pro�ssional e pessoal, me direcionaram em pesquisas anteriores e aceitaram
minha proposta de monogra�a que uniu as áreas de atuação de ambos, expresso aqui meu
mais sincero Obrigado.
Agradeço a todos que direto ou indiretamente me ajudaram, e peço desculpas se es-
queci algum nome, visto que sempre esqueço algo. Agradeço a todos.
GAME OVER (Rumo ao próximo nível).
RESUMO
Nóbrega, F. Aplicação de Lógica Descritiva para Validação de Requisitos
em Linha de Produto de Software
Curso de Ciência da Computação, Campus Catalão, UFG, Catalão, Brasil, 2010, 36p.
A abordagem de desenvolvimento software baseada em linha de produção é carac-
terizada por atender as necessidades e desejos de um determinado domínio de mercado
(hospitalar, gerenciamento de eventos, alimentar, etc.), gerando uma única arquitetura
e a utilizando como alicerce para instanciar componentes comuns à todo seu público e
componentes variáveis que atendam determinado sub-grupo de seu objetivo de mercado,
agregando gastos �nanceiros e temporais mais elevados nas fases iniciais de projeto. A�m
de amenizar tais custos iniciais, e diminuir o tempo de respostas desta abordagem de
desenvolvimento de sistemas computacionais, propomos a formalização de requisitos, ob-
jetivando automatizar o processo de validação de especi�cações desses. Aplicando Enge-
nharia de Conhecimento ao domínio abordado (Documentação de requisitos em Linha de
Produto de Software), compilar um modelo em Ontologia para representação destas infor-
mações e um conjunto de regras utilizadas para mapear requisitos (em outras linguagens
de especi�cação) para a especi�cação a representação formal adotada.
Palavras-Chaves: Representação de Conhecimento, Requisitos Formais, Linha de
Produto de Software, Lógica Descritiva, Validação de Requisitos
i
Sumário
1 Introdução 1
1.1 Fundamentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Distribuição do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Lógica Descritiva e Ontologia 6
2.1 Representação de Conhecimento . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Lógica Descritiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Ontologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Linha de Produto de Software 11
3.1 Abordagem SPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Requisitos em SPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Mapeamento de Requisitos SPL para Ontologia 16
4.1 Metodologia Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1 Determinar o domínio e escopo da Ontologia . . . . . . . . . . . . . 18
4.1.2 Considerar o reuso de Ontologias existentes . . . . . . . . . . . . . 19
4.1.3 Enumerar importantes termos da Ontologia . . . . . . . . . . . . . 19
4.1.4 Determinar classes e hierarquia de classes . . . . . . . . . . . . . . . 20
4.1.5 Levantamento de propriedades e facetas para as classes elaboradas . 21
4.1.6 Geração de regras de mapeamento . . . . . . . . . . . . . . . . . . . 23
4.2 Modelo de Representação Gerado . . . . . . . . . . . . . . . . . . . . . . . 25
5 Utilização de Ontologias para Requisitos 26
5.1 Descrição do Domínio Abordado . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 Incoerência em Especi�cação do Tipo de Dados . . . . . . . . . . . . . . . 27
5.3 Incoerência em especi�cação valorada . . . . . . . . . . . . . . . . . . . . . 28
5.4 Incoerência na Especi�cação de Dependência e Exclusão . . . . . . . . . . 29
ii
6 Conclusão 31
6.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3 Di�culdades Encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Referências 34
Apêndices 35
A Legenda 36
iii
Lista de Figuras
3.1 Comparação de custos entre SPL e SSD [Pohl et al., 2005]. . . . . . . . . 13
3.2 Modelo Ortogonal, especi�cação de variabilidade em SPL [Pohl et al., 2005].
14
4.1 Representação da taxonomia gerada para formalização de requisitos em
SPL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1 Especi�cação da característica de pesquisar artigos. . . . . . . . . . . . . . 28
5.2 Provador automático na especi�cação de pesquisar artigos. . . . . . . . . . 28
5.3 Especi�cação de usuários do sistema. . . . . . . . . . . . . . . . . . . . . . 29
5.4 Aplicação do provador automático na especi�cação de usuários do sistema. 30
5.5 Especi�cação de como o sistema trata submissão de artigos. . . . . . . . . 30
5.6 Aplicação do provador automático na especi�cação de submissão de artigos. 30
iv
Lista de Tabelas
2.1 Linguagem (ALC) utilizada para representar conceitos em DL. . . . . . . 8
2.2 Interpretação DL para Teoria dos Conjuntos. . . . . . . . . . . . . . . . . 9
4.1 Propriedades elicitadas para representação em SPL. . . . . . . . . . . . . 23
5.1 Especi�cação das propriedades de pesquisar artigos. . . . . . . . . . . . . . 28
5.2 Especi�cação das propriedades dos usuários. . . . . . . . . . . . . . . . . . 29
5.3 Especi�cação das dependências do componente Submeter Artigo. . . . . . . 30
v
Lista de Siglas
ADS Ambiente de Desenvolvimento de Software
DL Lógica Descritiva, do inglês Description Logics
ER Engenharia de Requisitos
KB Base de Conhecimento, do inglês Knowledge Base
ODE Ambiente de Desenvolvimento de Software Baseado em On-
tologias, do inglês Ontology-based Software Development En-
vironment
OWL Linguagem de Ontologia para Web, do inglês Ontology Web
Language
SPL Linha de Produto de Software, do inglês Software Product
Line
SSD Desenvolvimento de Sistema Único, do inglês Single System
Development
UML Linguagem de Modelagem Uni�cada, do inglês Uni�ed Mod-
eling Language
V Variantes, do inglês Variation
VP Ponto Variável, do inglês Variation Point
WWW Rede de Alcance Mundial, do inglês World Wide Web
XML Linguagem de Marcação Extensível, do inglês eXtensible Markup
Language
vi
Capítulo 1
Introdução
Este capítulo apresenta de forma super�cial os conceitos utilizados neste trabalho, a
motivação encontrada para este desenvolvimento, bem como o problema abordado e a
proposta para solução do mesmo.
1.1 Fundamentação
A engenharia de software depara-se com problemas observados ainda na fase de lev-
antamento de requisitos, fase esta que possui o objetivo de identi�car de forma concreta
as funcionalidades e regras que um sistema deve atender. Documentações incoerentes,
imprecisas e/ou ambíguas são problemas que levam em sua maioria à atrasos no desen-
volvimento de sistemas, acarretando a uma baixa da qualidade do produto [Neiva, 2009].
A abordagem de Linha de Produto de Software (SPL, do inglês Software Product Line),
diferencia-se do padrão de Desenvolvimento de Sistema Individual ou desenvolvimento
tradicional de softwares (SSD, do inglês Single System Development), pelo emprego da
prática de reutilização de seus artefatos e por tratar diferentes necessidades no projeto.
Tal metodologia é capaz de gerar produtos com algumas funcionalidades diferentes dentro
do domínio ao qual a Linha de Produto é desenvolvida.
As características da abordagem supracitada geram um maior custo inicial de projeto,
ocasionado pela necessidade de tratar as variações existentes dentro de um domínio de
mercado [Paul e Linda, 2001]. Fato objetiva este trabalho, pautando-se na possibilidade
de representar os requisitos e validá-los de maneira formal utilizando-se de uma linguagem
lógica e matemática.
A documentação de requisitos, seja a representação textual ou através de diagramas
UML (Linguagem de Modelagem Uni�cada, do inglês Uni�ed Modeling Language), em
suas necessidades de especi�car diferentes produtos quando emprega-se a abordagem de
linha de produto, busca auxílio no modelo ortogonal proposto em Pohl(2005) que, de
forma visual ou através de ligações, busca representar toda a especi�cidade bem como
1
suas relações.
Porém, a tarefa de veri�car a coerência e validar os requisitos é deixada de lado
nesta forma de especi�cação, �cando este processo a cargo da equipe de desenvolvimento.
Devido ao aumento da complexidade dos requisitos em SPL, quando comparada com SSD,
a veri�cação e validação acabam por exigir um custo maior e se tornam mais suscetíveis
à erros [Neiva, 2009].
Assim, este trabalho pauta-se na utilização da área de representação de conhecimento
juntamente com o processo de documentação de requisitos em SPL. Utilizando como
formalismo Lógica Descritiva (DL, do inglês Description Logic), mais especi�camente
Ontologias visto a viabilidade deste processo [Nóbrega et al., 2010], este trabalho visa
apresentar uma aplicação de engenharia de conhecimento e representação formal à fase
de elicitação de requisitos em SPL buscando uma metodologia para validação automática
da documentação, como meta diminuir o tempo gasto nessa atividade e ainda garantir a
qualidade sobre os requisitos elicitados.
Lógica de Descrição trata-se de um termo que refere-se a um conjunto de linguagens
lógicas para �ns da representação de conhecimento utilizadas em Inteligência Arti�cial.
Originadas de formalismos de representação de conhecimento da década de 1970, como
redes semânticas e quadros (frames) [Baader et al., 2003].
Dentre as maneiras de representação deste formalismo, está a utilização de Ontologias,
que de�ne-se como descrição formal de conceitos em um determinado domínio (classes ou
conceitos), propriedades de cada conceito descrevem suas características e/ou atributos
(regras ou propriedades), e restrições [Noy e McGuiness, 2009].
A junção destas duas áreas (Documentação para Validação de Requisitos e Lógica
Descritiva) se consolidará pela aplicação de conceitos de Engenharia de Conhecimento, que
constitui-se da aplicação de técnicas e métodos cientí�cos para representar determinado
conhecimento.
1.2 Objetivos
Exposto os conceitos e áreas de estudo utilizadas neste trabalho, apresentamos de
forma concisa nesta sessão os objetivos desta pesquisa.
1. Estudo de técnicas de representação de conhecimento em Ontologias para desen-
volvimento de um modelo capaz de representar as características de requisitos em
SPL, a �m de formalizar matematicamente o levantamento de validação e requisitos
desta metodologia de desenvolvimento;
2. Desenvolvimento de mecanismos de tradução entre os modelos habituais já utiliza-
dos na documentação de requisitos de softwares para Ontologia, e assim facilitar a
2
validação de requisitos já documentados;
3. Estudo de mecanismos de explicação de provas para serem aplicados às saídas gera-
das pelos provadores, possibilitando a compreensão dos resultados por pessoas sem
conhecimentos avançados em DL;
4. Compartilhar informações e resultados deste projeto em áreas de estudos voltados
à DL, explicação de provas bem como grupos de SPL, com intuito de aprimorar
conhecimentos, gerando uma pesquisa interdisciplinar.
1.3 Motivação
Na ânsia por desenvolvimento de sistemas computacionais mais complexos, com mais
qualidade e em tempo hábil, surge a abordagem de desenvolvimento de programas com-
putacionais em uma linha de produção [Paul e Linda, 2001].
Tal metodologia de desenvolvimento implica em maiores custos iniciais de tempo e
�nanceiro, atingindo habilidade de resposta (entrega de produtos) e obtenção de lucros
posterior a instância de um terceiro sistema [Pohl et al., 2005].
Partindo de que para esta abordagem, a fase de de engenharia de requisitos possui
grande importância, visto que tal etapa é apontado como um dos pontos chaves para se
trabalhar na solução dos problemas no desenvolvimento, devido as singulares da abor-
dagem em se atacar customização de produtos [Birk e Heller, 2007].
Assim sendo, este trabalho é motivado pela necessidade de se propor um modelo
de documentação de requisitos formal (representando em Ontologias) a�m de automati-
zar o processo de validação de requisitos, objetivando-se a diminuição de custos iniciais
referentes ao desenvolvimento de software em uma linha de produto. Diminuindo tais en-
travamentos iniciais e viabilizando com mais ênfase esta maneira de se produzir sistemas
computacionais.
1.4 Trabalhos Relacionados
Nesta seção é apresentando alguns trabalhos semelhantes ao abordado nesta obra,
apresentando ao leitor que a área abordada neste trabalho trata-se de fonte de interesse
de estudos cientí�cos.
É apresentando em [Nardi e de Almeida Falbo, 2006] o desenvolvimento de uma On-
tologia denominada ODE (Ambiente de Desenvolvimento de Software Baseado em On-
tologias, do inglês Ontology-based Software Development Environment). Pautado em es-
tabelecer uma conceituação básica para requisitos, servindo como base para a construção
de ferramentas de apoio ao processo de Engenharia de Requisitos (ER).
3
O trabalho supracitado apresenta uma Ontologia a�m de formalização do conheci-
mento sobre requisitos, seguindo métodos de engenharia de conhecimento semelhantes ao
utilizados neste trabalho. Sua distinção para com este, dá-se na geração de uma Ontologia
de propósito geral para requisitos, não tratando as singularidades da abordagem SPL.
Outra distinção do ODE, dá-se no seu desenvolvimento como sendo parte de uma
Ontologia maior denominada ADS (Ambiente de Desenvolvimento de Software) que visa
incluir todo o processo de desenvolvimento de sistemas computacionais. Este trabalho
a princípio aborda apenas a fase de ER, podendo futuramente estender-se para todo o
domínio da engenharia de software.
Outro processo de ER também voltado à SPL porém não formal (matemático ou
lógico), trata-se do RIPLE-RE (Requirements Engineering in Process for Product Line
Engineering, no português Engenharia de Requisito do Processos para Engenharia de
Linha de Produto) desenvolvido com apoio do grupo RiSE 1 [Neiva, 2009].
RIPLE-REEngenharia de Requisito do Processos para Engenharia de Linha de Pro-
duto, do inglês Requirements Engineering in Process for Product Line Engineering
O RIPLE-RE aborda um processo sistemático para ER. Sua abordagem dá-se no
emprego de três fases distintas sendo estas: Modelagem de Escopo, Modelagem de Re-
quisitos e De�nição de Casos de Usos; ressaltando os riscos da ER em SPL e propondo
maneiras para gerenciamento de variabilidade, apontando esta última característica com
ponto chave para os altos custos de ER em SPL.
Outra utilização de especi�cação formal de requisitos, é vista na utilização da lin-
guagem Z (pronuncia-se �Zed�) sendo esta caracterizada pela utilização de lógica de
primeira ordem, com sintaxe semelhante à linguagem Prolog. Trata-se de uma linguagem
de especi�cação formal de propósito geral [Moura, 2001].
1.5 Distribuição do trabalho
Distribuímos esta obra em três fases, sendo a primeira composta pela Fundamentação
Teórica, abordando as áreas de Representação de Conhecimento, Lógica Descritiva, On-
tologia (capítulo 2); Engenharia de Software com a Abordagem de Linha de Produto (3),
possibilitando ao leitor toda informação necessária para calça-lo com as características,
conceitos e singularidades das áreas de pesquisa aqui utilizadas.
A segunda parte, podendo ser de�nida como Prática, expõe a metologia de engenha-
ria de conhecimento adotada (capítulo 4), e posteriormente exempli�ca-se a utilização
da Ontologia gerada para documentação de requisito em Linha de Produto de Software
(capítulo 5).
1Reuse in Software Engineering
4
Tal fragmento do trabalho apresenta a forma na qual se buscou os objetivos aqui
propostos, e utilizando de situações �ctícias (plausíveis de acontecimento) onde há in-
consistências na elicitação e documentação de requisitos, apresentamos a viabilidade de
utilizar-se de um método formal representação nesta etapa de projeto.
A terceira parte compõe-se da conclusão, compilada com os resultados alcançados,
análises destes, propostas de trabalhos futuros e di�culdades encontradas durante o de-
senvolvimento deste trabalho.
5
Capítulo 2
Lógica Descritiva e Ontologia
Este capítulo aborda uma revisão dos conceitos de Lógica Descritiva e Ontologia,
apresentando também as ferramentas computacionais para manipulação de Ontologias
utilizadas neste trabalho; a �m de expor ao leitor, as terminologias referentes à Lógica
Descritiva e Ontologia que serão utilizadas posteriormente.
2.1 Representação de Conhecimento
Antes dos conceitos de Lógica Descritiva e Ontologia serem apresentados, nesta sessão
são de�nidos os conceitos de Representação de Conhecimento e Engenharia de Conheci-
mento. Para este propósito foram utilizados de�nições retiradas de Brachman(2004).
O termo conhecimento é fruto de grandes debates �losó�cos e passível também de
inúmeras interpretações. De forma habitual, conhecimento é tudo o que podemos dizer
sobre algo em especí�co. Neste exemplo retirado da bibliogra�a citada, temos a seguinte
sentença traduzida do inglês �John sabe que Mary vai a uma festa�, nesta sentença temos
dois pontos importantes para identi�car um conhecimento, sendo eles o conhecedor (John)
e uma proposição (Mary vai a uma festa).
O conhecedor é quem detém informação sobre algo e proposição é algo que podemos
tomar como verdadeiro ou falso. Dessa forma, o conhecedor é aquele que possui o conheci-
mento de fatos para dizer se determinada proposição é falsa ou verdadeira, analogamente
um indivíduo que não tem nada a pronunciar sobre determinada proposição não possui o
conhecimento deste assunto. Conhecimento são informações compartilhadas ou não sobre
determinado fato (proposições) [Brachman e Levesque, 2004]. Em nosso exemplo John
tem o conhecimento que a proposição �Maria vai a uma festa� é verdadeira.
O conhecimento de maneira individual não garante a habilidade de conhecer, para isso
torna-se necessário um método de representá-lo, exigi-se assim um conjunto de símbolos
para que este conhecimento possa ser �armazenado� pelo conhecedor, possibilitando infe-
rências sobre os fatos e compartilhar estas informações. De�nindo assim representação de
6
conhecimento como área de estudo interessada no uso de símbolos formais (matemáticos
e/ou lógicos) para representar um conjunto de proposições em que um determinado agente
acredita [Brachman e Levesque, 2004].
De posse da de�nição de conhecimento e representação de conhecimento nos parágrafos
anteriores partimos para o conceito de Engenharia de Conhecimento. Usando a de�nição
da palavra engenharia do dicionário [Bueno, 1996]: �técnica e arte da construção de obras
de grande porte, mediante a aplicação de princípios matemáticos e das ciências físicas�;
engenharia de conhecimento seria a aplicação de técnicas e métodos cientí�cos para se
representar determinado conhecimento.
Especi�cando um conjunto de passos para obtenção de êxito à construção da Base de
Conhecimento (KB, do inglês Knowledge Base), sendo esses podendo ser expressos nas
seguintes fases:
1. Escolha da linguagem de representação (neste trabalho usou-se Ontologia explicadas
mais detalhadamente em sessões subsequentes);
2. Descrição do domínio: onde são especi�cadas características mais simples do que
queremos representar;
3. Descrição mais detalhada do domínio: aprofundamos com maior riqueza de detalhes
nas características do domínio;
4. Taxonomia: geração da hierarquia dos conceitos;
5. Geração de indivíduos: nesta etapa desenvolve-se, caso necessário, instancias dos
conceitos de�nidos.
Concluindo assim a terminologia presente no âmbito das áreas de Representação de
Conhecimento e Engenharia de Conhecimento, no decorrer deste capítulo é apresentada
a linguagem formal escolhida para representação de conhecimento e seus conceitos.
2.2 Lógica Descritiva
Lógica Descritiva (DL, do inglês Description Logics) trata-se de um termo que refere-se
a um conjunto de linguagens lógicas para �ns da representação de conhecimento utilizadas
em Inteligência Arti�cial. Originadas de formalismos de representação de conhecimento
da década de 1970, como redes semânticas e quadros (frames) [Baader et al., 2003].
Em DL, conceitos descrevem classes de indivíduos dentro de um universo (que especí-
�ca os possíveis indivíduos), e papéis ou propriedades que descrevem a ligações entre tais
indivíduos. Para se encontrar tais características devem-se notar peculiaridades chaves
do domínio (o que se quer representar, ou alvo de representação).
7
Em uma analogia com a programação de um sistema orientado à objetos temos que,
conceitos em DL seriam as classes de objetos, e as propriedades seriam os métodos e
relações entre as classes de objetos existentes e domínio o sistema que se está desenvol-
vendo, enquanto regras (também chamadas propriedades) representam relações binárias
conectando indivíduos.
Neste trabalho, a sintaxe de conceitos e propriedades será de�nida pela gramática
descrita na tabela 2.1, onde R representa a regra (propriedade). Esta é gramática corres-
pondente da linguagem lógica conhecida com ALC.
Uma maneira usual de interpretar conceitos é traduzi-los para expressões em teoria
dos conjuntos. De maneira formal, uma interpretação é de�nida com uma aplicação I do
conjunto de conceitos dos indivíduos em um universo ∆ e de regras para relações binárias
sobre ∆ satisfazendo as condições expressas na tabela 2.2.
Tabela 2.1: Linguagem (ALC) utilizada para representar conceitos em DL.
C, D → A (conceito atômico)
| > (conceito universal)
| ⊥ (conceito vazio)
| ¬C (negação)
| C u D (interseção)
| C t D (união)
| ∀R.C (restrição de valor)
| ∃R.C (quanti�cação existencial)
Uma fórmula de subsunção1 em DL, escrita C v D, representa a a�rmação de que a
classe denotada por C esta contida na classe denotada por D. Uma fórmula de equivalência
C ≡ D representa a declaração de que C subsume2 D e D subsume C. exemplo: ambos
C e D denotam a mesma classe.
Se um indivíduo a pertence ao conjunto representado pelo conceito C, diz-se que a
está em C. Se um par (a, b) de indivíduos estão na relação binária representada por
R, dizemos que b é um preenchedor para a propriedade R de a estão na relação binária
representada por R, dizemos que b é um enchimento para R propriedade de a.
Informalmente, um conceito da forma ∀R.C representa o conjunto de todos os indi-
víduos tendo todos os preenchedores para R em C (podendo ser vazio). Um conceito da
forma ∃R.C representa o conjunto de todos indivíduos tendo pelo menos um preenchedor
para R em C.
As consultas a uma KB em DL se dão de três maneiras, fazendo com que o trabalho
1Formulá para especi�cação de subclasses.2Dizemos que C subume D quando C é subclasse de D.
8
Tabela 2.2: Interpretação DL para Teoria dos Conjuntos.
I(>) = ∆
I(⊥) = ∅I(¬C) = ∆− I(C)
I(C u D) = I(C) ∩I(D)
I(C t D) = I(C) ∪I(D)
I(∀R.C) = { a ∈ ∆ | ∀b.[(a, b) ∈ I(R)⇒ b ∈ I(C)]}I(∃R.C) = { a ∈ ∆ | ∃b.[(a, b) ∈ I(R) ∧ b ∈ I(C)]}
de provadores automáticos seja veri�car se determinada fórmula, é consequência lógica de
uma TBox3:
1. Insatisfabilidade: veri�ca se um determinado conceito ou propriedade não é uma
representação aceita pela KB;
2. Equivalência: veri�ca se dois ou mais conceitos ou propriedades são equivalentes;
3. Disjunção de conceitos: veri�ca a disjunção de dois ou mais conceitos na KB.
A próxima sessão apresenta conceitos sobre Ontologias, que trata-se de uma forma de
utilização da DL, sendo esta a forma adotada para este trabalho.
2.3 Ontologia
Dentre as maneiras de representação em DL está a utilização de Ontologias, sendo esta
uma descrição formal de conceitos em um determinado domínio (classes ou conceitos),
as propriedades de cada conceito descrevem suas características e atributos (regras ou
propriedades) e restrições. Podendo também ser de�nida como um conjunto de instâncias
individuais de classes caracterizando uma KB [Noy e McGuiness, 2009].
Partindo da analogia do desenvolvimento de um sistema orientando a objetos anteri-
ormente aplicada à DL, podemos dizer que, Ontologia exempli�ca-se também por esta,
adicionando as representações de instâncias individuais seriam análogas aos objetos ins-
tanciados no sistema. Sendo a KB a representação completa do sistema desenvolvido.
Para nossos trabalho uma Ontologia é um DL TBox (conforme seção 2.2), seguindo o
proposto em [Gruber, 1993].
Adicionalmente uma Ontologia consiste em um conjunto de conceitos e regras, sendo
capaz de representar uma hierarquia entre tais conceitos. Toda essa representação, por
si só armazena dados que sendo interpretados geram conhecimento que foram inseridos
3Conjunto de todos os conceitos e fórmulas de subsunção armazenadas na KB
9
explicitamente pelo engenheiro de conhecimento ou agentes externos, porém, tais pro-
priedades podem gerar e normalmente geram outras propriedades de subsunção implíci-
tas, formando novos conhecimentos sobre o mundo. Assim caracterizando o processo de
Classi�cação de Ontologia, processo que justi�ca a importância de conhecer tais maneiras
de consultas à KB.
O estudo desta área hoje de forma mais abrangente se mostrou importante para o de-
senvolvimento da Web Semântica [Mcguinnes e Borgida, 1995] e [Bechhofer et al., 2009]
que consiste em uma base de dados para que agentes inteligentes de software possam
manipular e consultar estes dados. A Linguagem de Ontologia para Web (OWL, do in-
glês Ontology Web Language) fornece os formalismos DL em uma sintaxe XML de fácil
integração com aplicação da WWW, e assim capacitando agentes de software trocarem
informações sobre aplicações (conhecimentos inseridos na base de dados) e inferir novos
conhecimentos sobre os dados.
Para este trabalho, DL e Ontologia são a base para atingir os objetivo proposto, o
qual é a criação de um modelo em Ontologia para formalização de requisitos SPL, agindo
como sintaxe de formalização e representação do domínio de requisitos de software em
SPL. Outros fatores relevantes para justi�cativa do uso de DL são abordados no capítulo
3.
Para construção dos modelos formais e ferramentas computacionais a �m de atender
os objetivos deste trabalho, foram utilizados softwares listados a seguir:
1. Protégé4:software destino a criação e edição de Ontologias;
2. Graphviez5: utilizado juntamente com o Protégé para geração de grafos represen-
tando o comportamento da KB.
4http://protege.stanford.edu/5http://www.graphviz.org/
10
Capítulo 3
Linha de Produto de Software
Neste capítulo é apresentada uma revisão sobre Linha de Produto de Software (SPL,
do inglês Software Product Line), suas terminologias e características. Assim sendo, é
ressaltado a importância de uma representação formal de requisitos para esta abordagem
de desenvolvimento de sistemas, sendo apresentadas as justi�cativas para formalização de
requisitos.
3.1 Abordagem SPL
SPL é uma importante estratégia de reuso para minimizar custos e tempo de entrega
de aplicações, bem como maximizar a qualidade e produtividade do desenvolvimento de
software. Podendo também ser conceitualizada como um conjunto de sistemas de softwares
que compartilham um conjunto de features (características) comuns e gerenciáveis, que
satisfazem as necessidades de um segmento de mercado particular [Paul e Linda, 2001].
SPL trata-se de uma abordagem distinta de SSD, sendo esta última abordagem carac-
terizada por tratar cada sistema como um único produto do início ao �m de seu desen-
volvimento, visando atender as necessidades de um cliente (ou outros clientes que tenham
os mesmos interesses ao sistema) em particular, tratando projetos mesmo que semelhantes
em seus objetivos como produtos diferentes.
O objetivo central da SPL está calcado em atender as necessidades de um determinado
domínio (hospitalar, gerenciamento de eventos, alimentar, etc.), gerando uma única ar-
quitetura e a utilizando como alicerce para instanciar componentes comuns e variáveis que
atendam determinado grupo de seu mercado, alcançando assim com maior abrangência
o conjunto de expectativas desejadas pelos stakeholders1. Enfatizando também a qua-
lidade de seus produtos, pressupondo do arti�cio de maturação de seus componentes e
reutilizando-os posteriormente.
1Indivíduos diretamente ou indiretamente relacionadas ao produto (software) em construção, como
exemplo: compradores, desenvolvedores, investidores, usuários �nais, etc.
11
Para expor com mais clareza SPL, partiremos do pensamento natural de relacionar a
expressão linha de produto com materiais físicos como eletrônicos, roupas, automóveis,
etc., en�m com fabricação de produtos em grande escala. Pohl(2005) apresenta uma
analogia de SPL com uma montadora de automóveis.
O produto �nal de uma montadora automobilística possui o objetivo principal de
viabilizar um meio de transporte ao seu usuário, mas seus clientes possuem interesses,
desejos e expectativas diferentes para com o veículo, seja quanto a conforto, segurança,
cor, praticidade, dentre outros. Pautada nessas necessidades a linha de produção admite
itens que podem distinguir um automóvel de outro, visando atingir as expectativas de um
maior público.
Como exemplo podemos citar o sistema de direção de um automóvel, ao qual possui
objetivo de capacitar ao condutor mecanismos para mudanças de direção do veículo, mas
seus usuários podem possuir preferências por um sistema de direção mecânico, hidráulico
ou elétrico. A fábrica produzindo carros com estas possibilidades de escolha de direção
atingirá uma gama maior de clientes sem deixar de atingir o objetivo principal de seu
produto.
Assim é SPL, temos que os sistemas nesta abordagem possuem objetivos semelhantes
(ou mesmos), de modo a atingir as necessidades de seus stakeholders, há pontos nos
produtos que devem variar. Assim, o ponto chave de SPL está na Variabilidade2, propondo
uma customização do sistema, para diferentes interesses, onde componentes no sistema
necessitam comportar-se distintamente em uma determinada instância do produto para
atingir diferentes necessidades de um grupo de seu domínio.
Destacam-se dois pontos chaves em SPL:
• Ponto variável: VP (Variation Point), um requisito do sistema alvo de necessidades
diferentes, que pode ser customizado;
• Variantes: V (Variation) é a maneira de atender um determinado objetivo do ponto
variável;
A complexidade relacionada no desenvolvimento de uma SPL impacta diretamente
nas fases iniciais de projeto, in�uenciando em um maior custo em investimento e de
tempo. Esta a�rmativa indica certa precaução para se optar pela implantação de uma
SPL, sendo suas vantagens e retorno de investimento alcançadas em média, a partir do
desenvolvimento do terceiro produto da linha [Pohl et al., 2005].
Este cenário é retratado na �gura 3.1, a qual traz uma comparação entre os custos
empregados em uma SPL em relação à SSD, tendo como medida a quantidade de produtos
instanciados com o tempo. Observa-se que o custo inciais da SPL (linha tracejada) é
2Capacidade ou a tendência de alteração [Pohl et al., 2005].
12
mais elevado em relação à SSD (linha contínua), no entanto se equipara após 3 sistemas
e posteriormente tendo um custo menor.
Figura 3.1: Comparação de custos entre SPL e SSD [Pohl et al., 2005].
É relevante também destacar que a documentação de requisitos ganha maior grau
de importância relacionado ao fato do reuso, onde todo produto em SPL os quais de-
nominados assets (códigos, documentação, diagramas, etc), deve ser bem documentado e
rastreável.
Neste contexto um assets rastreável é aquele que possui documentação que se pode con-
sultar posteriormente para veri�car em quais outros assets esse impacta, permitindo total
compreensão de objetivos e dependências em futuras consultas. Dessa forma possibilitar
a inclusão destes assets em desenvolvimento de sistemas posteriores sem comprometer a
con�ança e qualidade dos produtos gerados, o que também contribui para a diminuição
de tempo de desenvolvimento.
Para melhor separação deste assunto, a sessão a seguir trata mais detalhadamente da
importância e das di�culdades da licitação de requisitos dentro da abordagem SPL.
3.2 Requisitos em SPL
A Engenharia de Requisitos em SPL, se depara com todas as di�culdades existentes na
metodologia SSD, sendo agravada pela obrigatoriedade de tratar em sua especi�cação a
característica de variabilidade, tornando o processo de elicitação e validação de requisitos,
mais complexos e consequentemente detentores de maiores gastos �nanceiros e de tempo
[Neiva, 2009] e [Pohl et al., 2005].
Um modelo desenvolvido para auxiliar a elicitação de requisitos em SPL é o Mo-
delo Ortogonal, que através de elementos grá�cos e/ou links busca representar os pontos
variáveis (VPs), suas variações (Vs), dependências e con�itos existentes nos requisitos
13
[Pohl et al., 2005].
Utilizaremos o modelo supracitado, a�m de ser um guia para elicitar requisitos e de�nir
suas especi�cidades em SPL. Tal modelo é apresentando na �gura 3.2.
Figura 3.2: Modelo Ortogonal, especi�cação de variabilidade em SPL [Pohl et al., 2005].
Com a análise deste modelo, podemos distinguir que requisitos em SPL devem ser
especi�cados com:
1. Variation Point (VP): requisito que representa diferentes necessidades dentro do
domínio ao qual é proposto a SPL, ponto do sistema que pode variar, que pode ser
customizado. De forma simpli�cada descreve objetivos;
2. Variation (V): são as distintas formas que os produtos podem assumir para atender
os objetivos representados pelos VPs;
3. Variability Dependencies (Dependência de Variabilidade): especi�ca quais são os
requisitos comuns ao domínio (requisitos mandatórios), e quais são opcionais (re-
quisitos opcionais);
4. Alternative Choice (Escolhas Alternativas): representa a quantidade mínima e má-
xima (caso exista) de variações que um sistema deve ou pode instanciar a partir de
um determinado VP;
5. Artefact Dependency (Dependência do Artefato): representa dependência entre artefatos
na documentação;
6. Constraint Dependecies (Dependências de Restrições): especi�ca as relações de de-
pendências e exclusões (requisitos con�itantes) entre V e V, V e VP, VP e VP.
14
A complexidade em se documentar requisitos em SPL, pauta-se em sua necessidade
de Variabilidade, sendo este conceito que agrega ao processo uma quantidade maior de
relações entre componentes, maiores riscos com a não detecção de erros, visto que um
erro na arquitetura de�nida in�uenciará vários produtos, o que impacta diretamente no
custo iniciais mais elevado da utilização de SPL.
Assim sendo, a etapa de elicitação e validação de requisitos é uma fase de grande
importância para SPL, visto que a engenharia de requisitos é apontado como um dos
pontos chaves para se trabalhar na solução dos problemas no desenvolvimento em SPL
[Birk e Heller, 2007].
15
Capítulo 4
Mapeamento de Requisitos SPL para
Ontologia
Este capítulo pauta-se na apresentação do mapeamento de requisitos SPL para Ontolo-
gia, porém, expondo antes a metodologia de engenharia de conhecimento abordada neste
trabalho, apresentando as fases de elaboração, ferramentas computacionais utilizadas,
execução de testes realizados para veri�cação da representação e posteriores correções no
modelo.
4.1 Metodologia Utilizada
A engenharia de conhecimento trata-se de um processo iterativo (vide seção 2.1) de
caráter tentativa e erro, assim sendo, a metodologia utilizada neste trabalho não foi apli-
cada de forma linear, oscilando entre suas etapas para correção das classes, hierarquia e
propriedades da Ontologia.
O processo utilizado trata-se de uma adaptação da metodologia para engenharia de
conhecimento apresentada em [Noy e McGuiness, 2009], que constitui-se em um processo
interativo partindo da criação de uma Ontologia mais simples e abstrata, posteriormente
aplicando suas etapas em ciclo a�m de compilar a Ontologia para uma representação mais
completa. Sendo este composto pelas respectivas etapas:
1. Determinar o domínio e escopo da Ontologia: de�nição dos objetivos e informações
que deverão ser representadas;
2. Considerar o reuso de Ontologias existentes: veri�cação da possibilidade de utiliza-
ção de uma Ontologia já existente, ou para posterior utilização da Ontologia a ser
desenvolvida em outros projetos;
16
3. Enumerar importantes termos da Ontologia: listagem dos pontos característicos
(pontos chaves) do domínio adotado;
4. Determinar classes e hierarquia de classes: criação dos conceitos (classes) e da ta-
xonomia regente para estes;
5. De�nição das propriedades das classes: elaboração das propriedades (relações de
um conceito para com outro) de cada classe;
6. De�nir as facetas dos slots: de�nição das restrições (atributos) de cada conceito e
de�nição do possíveis valores que estes possam assumir;
7. Criar instâncias.
Nossa adaptação distingui-se da supracitada metodologia por 3 fatores. Primeiro, a
combinação das etapas 5 e 6 da abordagem acima em uma fase apenas. Segundo, não
utilização da etapa 7, esta etapa não se mostrou necessária para a geração da Ontologia
objetivo deste trabalho porém. Por �m, pela inserção de duas fases de execução de testes.
A metodologia por nós aplicada, caracteriza-se pelas etapas abaixo e individualmente
detalhadas nas subseções posteriores.
1. Determinar o domínio e escopo da Ontologia;
2. Considerar o reuso de Ontologias existentes;
3. Enumerar importantes termos da Ontologia;
4. Determinar a classe e hierarquia de classes;
5. Levantamento de propriedades e facetas para as classes elaboradas;
6. Testes da Ontologia gerada;
7. Geração de regras de mapeamento;
8. Testes das regras.
Nas subseções à seguir são detalhadas as etapas da metologia adotada, com exceção
das etapas de testes. Assim sendo são apresentadas suas respectivas de�nições, objetivos,
resultados e di�culdades encontradas.
17
4.1.1 Determinar o domínio e escopo da Ontologia
Nesta fase de�nem-se os objetivos e informações que deverão ser representadas pela
Ontologia, assim sendo utilizamos do emprego de quatro questionamentos apresenta-
das por Noy e McGuiness(2009), a�m de sistematizar a maneira como abordamos nosso
domínio.
• Qual o domínio que a Ontologia deverá abordar?
• Por quê vamos usar a Ontologia?
• Quais tipos de questões as informações na Ontologia deverão tentar responder?
• Quem irá usar e/ou manter a Ontologia?
Com as respostas destas quatro questões podemos sistematizar a de�nição de nosso
objetivo de representação. Abordando o domínio de Requisitos de software em SPL enfa-
tizando as características representadas pelo Modelo Ortogonal proposto por Pohl(2005),
aplicando Ontologias a�m de automatizar o processo de validação de requisitos objeti-
vando diminuição de custos �nanceiro e/ou de tempo de desenvolvimento das fases inciais
de uma SPL.
A Ontologia proposta deve armazenar e distinguir os requisitos de uma SPL em par-
ticular, caracterizando-os de acordo com as singularidades apresentadas pela abordagem
de desenvolvimento de software adotada. Assim sendo, deve ser capaz de responder quais
requisitos são VPs e Vs, mandatórios ou opcionais, além de tratar as relações entre estes
como dependência, hierarquia entre VPs e Vs, exclusões, cardinalidade de componentes
opcionais.
Possuindo público alvo para utilização e manutenção, indivíduos envolvidos em pro-
cessos de Engenharia de Requisitos em SPL, seja estes membros da equipe desenvolvedora,
clientes ou usuários �nais do sistema. A Ontologia proposta neste trabalho possui ele-
mentos que viabilizem o emprego de métodos automáticos de provas e campos em sua
descrição de modo a facilitar sua interpretação por pessoas sem o conhecimento técnico
em Lógica Descritiva.
Ressaltamos também a distinção e necessidades das pessoas que poderão utilizar-se
desta Ontologia, seja a equipe de desenvolvimento, cliente ou usuários, viabilizando o
emprego de maior conjunto de características dos requisitos relacionados aos níveis da
informação sendo mais técnico para os desenvolvedores e mais objetivos, descrevendo
características do sistema, para cliente e usuários.
18
4.1.2 Considerar o reuso de Ontologias existentes
Este trabalho não baseou-se em Ontologias para representação de requisitos em SPL
ou SSD já existentes, porém este fase torna-se importante para elicitar os componentes
da Ontologia desenvolvida neste trabalho que possam ser posteriormente reutilizados em
outros projetos ou pesquisas.
Os principais pontos que apresentamos para posterior reutilização seriam as de�nições
de requisitos VP e V, representação de requisitos mandatórios e opcionais, nível de reuti-
lização de requisitos e nível de prioridade para se implementar determinado requisito nos
sistemas.
Estas características são vigentes dentro do domínio de SPL, sendo assim importantes
de�nições que possam ser reutilizadas posteriormente.
4.1.3 Enumerar importantes termos da Ontologia
Nesta etapa do processo, devemos listar do domínio abordado o quê queremos repre-
sentar, quais conceitos iremos descrever, identi�car as possíveis maneiras de explicação
destes conceitos aos usuários. Ou seja, descrito o domínio de uma forma mais geral na
etapa anterior, agora o especializamos em um nível menos abstrato visando caracterizar
os elementos do domínio.
Analisando o modelo Ortogonal (vide �gura 3.2) e as bibliogra�as objetivadas à
de�nição de requisitos usando SPL referenciadas neste trabalho, observa-se as singu-
laridades desta abordagem em linha de produção de desenvolvimento de software, enu-
merando então, os seguintes termos:
1. Requisitos podem ser Ponto de Variação (VP), Variação (V) ou nenhum destes;
2. Um VP possui variações (Vs);
3. Requisitos podem ser Mandatórios ou Opcionais;
4. Um VP opcional, pode conter variações mandatórias (necessárias para utilização do
VP opcional);
5. Requisitos podem exigir a existência ou exclusão de outro componente no sistema;
6. Um VP pode possuir cardinalidade para instanciar suas variações na linha;
7. Um requisitos possui nível de reutilização em outros produtos;
8. Requisitos possuem prioridades distintas para serem implantados nos produtos;
19
4.1.4 Determinar classes e hierarquia de classes
Determinado os principais conceitos do domínio, nesta fase iremos descrever as respec-
tivas classes em Ontologia1. Este processo pode ser executada de três formas distintas:
1. Top-Down (de cima para baixo): quando iniciamos a de�nição das classes mais
genéricas e posteriormente as mais especí�cas;
2. Botton-up (de baixo para cima): o processo se inicia pela criação das classes mais
especí�cas e em seguida realizando comparações entre as similaridades entre as
entidades especi�cadas de�nem-se as classes mais genéricas;
3. Combinação: há a combinação das duas formas supracitadas.
Sendo estas abordagens equivalentes, ou seja, nenhuma é melhor do que outra; a es-
colha de uma destas pelos desenvolvedores de Ontologia é de caráter simplesmente pessoal,
ou por familiarização com o método. Neste trabalho optamos pela abordagem de Combi-
nação, visto que, se trata de mecanismo mais simples (não linear) e que auxilia diretamente
o processo iterativo de Engenharia de Conhecimento adotado [Noy e McGuiness, 2009].
A taxonomia (hierarquia de classes) criada foi compilada para representação de con-
ceitos como: tipos de dados, tipos de requisitos em SPL, prioridade de implantação,
nível de reusabilidade. Chegando no grafo apresentando na �gura 4.1. Que representa a
hierarquia de classes gerada inicialmente, composto pelas classes:
1. RequirementsType: representa os possíveis tipos de requisitos existentes em uma
SPL, sendo esta composta pelas subclasses Optional e Mandatory representando
requisitos opcionais e mandatórios respectivamente;
2. Reusability: descreve os possíveis níveis de reuso de um requisito para outros pro-
dutos ou para a SPL, sendo esta composta pelas classes Weak, Maybe e Certainly as
quais representam respectivamente requisitos que fracamente, talvez e certamente
serão reutilizados;
3. Priority: descreve a prioridade de se empregar determinado requisito na SPL, sendo
esta compostas pelas classes Low, Medium e High representando respectivamente os
níveis baixo, médio e alto de prioridade para se empregar determinado requisito;
4. Requirement: utilizada para compor a classe mais geral para os requisitos de uma
SPL a ser desenvolvida;
1A nomenclatura de classes em Ontologia por padrão são escritas em língua inglesa, evitando possíveis
empecilhos com acentuação que podem prejudicar a utilização de provadores automáticos e/ou agentes
de software
20
Figura 4.1: Representação da taxonomia gerada para formalização de requisitos em SPL.
5. DataType: representa os possíveis tipos de dados que podem ser utilizados para
representação ou de�nição de requisitos na SPL, a princípio de�nimos as subclasses
(tipos de dados): Boolean, Float, Integer, List, String e Vector.
A utilização de Thing como sendo a classe mais geral é um padrão utilizado para
representação de Ontologias e automaticamente inserido pelo software Protégé.
4.1.5 Levantamento de propriedades e facetas para as classes
elaboradas
De�nida as classes em Ontologia, nesta etapa do processo geramos suas respectivas
propriedades, para que, as de�nições do domínio de requisitos de software em SPL, deta-
lhados no capítulo 3, foi esquematizado em um processo de engenharia de conhecimento,
21
sessões 4.1.1 e 4.1.3, de modo a possibilitar sua representação através de Ontologias de
forma correta.
Uma propriedade em Ontologia é a caracterização de uma relação binária de de-
terminado conceito (classe) com outro conceito ou atributo (tipo de dado e respectivo
valor), sendo a primeira forma (conceito relacionado com outro conceito) denominada
Propriedade de Objeto e a segunda (conceito relacionando com atributos) nomeada como
Propriedade de Dado.
Outra forma de especi�cação de propriedades de classes é a Propriedade de Anotação,
utilizada em geral para especi�cação de Meta-Dados, em nosso trabalho utilizada para
representação de comentários das especi�cações de cada classe2 [Horridge et al., 2004].
Interpretando tais propriedades no âmbito da teoria de conjuntos (tal tipo de inter-
pretação foi abordada no capítulo 2), estas seriam caracterizadas como funções de mapea-
mento de domínio para um contra-domínio, ou seja, de um conceito para outro ou de um
conceito para um dado. Por exemplo, uma propriedade que relaciona determinado Re-
quisito R com sua Prioridade de Implantação PI, há uma função (relação) F que mapeia
os conceitos de Requisitos para conceitos de Prioridade, assim interpretamos que F (R) =
PI .
Podemos distinguir estas relações de acordo com suas especi�cidades, em outras palavras,
conforme seu objetivo e como ela relaciona os conceitos. Desta forma temos os seguintes
tipos de propriedades:
1. Funcional: quando uma propriedade P relaciona um conceito C1 a apenas um outro
conceito C2. Ou seja, o emprego de P(C1) sempre retornará C2;
2. Inversa: quando existe uma propriedade P1 que mapeie o resultado de uma pro-
priedade P2 de determinado conceito C para este. Ou seja, P1[ P2( C ) ] = C;
3. Transitiva: análogo a propriedade de transitividade da matemática. Então, seja P,
C1, C2, C3 uma propriedade e três conceitos respectivamente, se P( C1 ) = C2 e
P( C2 ) = C3, pela transitividade tempos que P( C1 ) = C3;
4. Simétrica: uma propriedade P caracteriza-se como simétrica quando dado dois con-
ceitos C1 e C2, temos que P( C1 ) = C2 e P( C2 ) = C1.
Tais propriedades podem ser lidas de diversas maneiras, conforme sua utilização e
objetivo. De forma geral, podemos expor que tais propriedades são caracterizações das
seguintes relações (ou interpretações):
2Esta representação foi adotada para facilitar a utilização da Ontologia aqui gerada por indivíduos
que não possuam o conhecimento técnico em Ontologias.
22
1. É parte de: representa conceitos compostos, que sua descrição é composta por
outro conceito. Em nosso domínio podemos exempli�car tal interpretação com um
requisito R que possui um tipo de dado T para especi�cação. Por padrão estas
propriedades possuem nomes iniciados com o pre�xo has do inglês possui;
2. É um: representa relações de identi�cação entre conceitos, podendo ser exempli�-
cada como uma propriedade que mapeie requisitos (Requirement) para seus respecti-
vos tipos (RequirementsType composto por Mandatory ou Optional ). Muitas vezes
esta interpretação é utilizada como propriedade inversa à propriedade anterior. A
padronização desta propriedade propõe sua escrita iniciada com o pre�xo is.
Já de�nido o termo Propriedade em Ontologias, apresentamos na tabela 4.1 as relações
criadas para o domínio. Observando inicialmente necessário a criação de propriedades de
anotação para utilização de comentários, a�m de, auxiliar indivíduos não familiarizados
com o desenvolvimento de Ontologias.
Tabela 4.1: Propriedades elicitadas para representação em SPL.
Nome Interpretação Domínio Contra-Domínio
isRequirementType É um tipo de requisito Requirement RequirementType
hasDependecy Tem dependência com outro requisito Requirement Requirement
hasObjective Possui como objetivo Requirement string
hasPriority Possui prioridade Requirement Priority
hasReusability Possui nível de reutilização Requirement Reusability
Com estas propriedades de�nidas é possível representar o tipo do requisito (Manda-
tory ou Optional, veri�car a dependência e exclusão (con�itos)de requisitos, veri�car a
prioridade de implantação e nível de reutilização de um requisito em particular.
Uma particularidade encontrada nestas propriedades, é que, apenas uma (hasObjec-
tive) trata-se de uma Propriedade de Dado, mapeando requisitos (classe Requirement)
para o tipo de dado string. Esta é utilizada para especi�car de forma textual o objetivo
do requisito, assim sendo, um requisito cuja descrição é Cadastrar Usuário, este objetivo
sera abordado por esta propriedade.
4.1.6 Geração de regras de mapeamento
Nesta seção apresentamos o conjunto de regras que devem ser utilizadas para mapear
requisitos seja qual for sua forma de documentação, para Ontologia, utilizando como
base as classes e propriedades de�nidas nas seções anteriores deste capítulo. Tais regras
de�nem os mecanismos de formalização de requisitos em SPL para Ontologia com auxilio
do software Protégé.
23
Enumeramos as seguintes regras:
1. Requisitos: todo requisito deve ser sub-classe (direta ou indiretamente) da classe
Requirement;
2. Especi�cação de Requisitos: toda forma de especi�cação de requisitos (suas caracte-
rísticas) deve possuir uma propriedade de objeto que a represente. Ex.: Um usuário
para o sistema possui nome, senha, endereço, assim, para todas estas características
será desenvolvida uma propriedade hasNome, hasSenha e hasEndereco, cujo domínio
será o conceito que de�ne um usuário e contra-domínio algum outro conceito que
de�ne tal propriedade (String, Integer, etc.) que represente o tipo do campo;
3. Especi�cação Valorada de Requisitos (cuja de�nição é apresentada na seção 5.3):
para toda propriedade de requisito que possua um valor em especí�co, deverá ser
criada uma propriedade de dado que a represente. Ex.: Tamanho máximo do campo
senha do usuário, cria-se uma propriedade de dadohasSenhaMax, cujo domínio é
usuário e seu contra-domínio o tipo de dado integer, e assim, quando utilizar-se
desta propriedade especí�ca-se o valor;
4. Caracterização de V e VP: todo V de determinado VP, deverá ser sub-classe do
mesmo;
5. Regras de um VP: toda propriedade e/ou de�nição de um VP, deverá ser repre-
sentada no campo Classe de Equivalência3 utilizando o quanti�cador only seguido
de um and e a classe a ser de�nida. Ex.: Usuário possui senha do tipo string,
mapeamos em Ontologia com Usuario and hasSenha only String;
6. Regras de um V: toda especi�cação de um V oriunda de seu VP, deverá ser especi-
�cada no campo Super Classe utilizando o quanti�cador some;
7. Prioridade: a prioridade de determinado requisito será representada com a pro-
priedade hasPriority (tem Prioridade), mapeando o requisito para o escopo do con-
ceito Priority (Prioridade), utilizando os valores Low,Medium e High (representando
respectivamente níveis Baixos, Médios e Altos de prioridade);
8. Reusabilidade: este conceito será representado pela propriedade hasReusability (pos-
sui reusabilidade), mapeando requisitos para o escopo de Reusability (Reusabili-
dade), especi�cado por Wask, Maybe e Certainly (fracamente, talvez e certamente
reutilizado);
3Este campo de determinado conceito C representa as regras que outro conceito D deve respeitar para
se tornar subclasse de C.
24
9. Requisito Mandatório : para auxiliar usuários, pode-se utilizar a propriedade is-
RequirementType (é um tipo de requisito), que mapeia requisitos para Mandatory
(Mandatório) e Optional (Opcional) - Escopo do conceito RequirementType (Tipo
de requisito) - porém, tal representação em Ontologia é de�nida com a especi�-
cação de conjunto, utilizando operadores lógicos (E Lógico e Ou Lógico). Ex.: Seja
R1 Mandatório e R2 Opcional, ambos são sub-classes de Requirements, então na
especi�cação desta última haverá R1 or R2. Tal utilização é também válida para
especi�car Vs opcionais de um VP;
10. Dependência: esta característica presente na documentação de requisitos, será abor-
dada com a utilização da propriedade hasDependecy (possui dependência), sendo es-
tas sempre com a utilização do quanti�cador only. Ex.: Se um requisito R1 depende
de R2 então, hasDependecy(R1) = R2;
11. Exclusão: Nega-se a propriedade hasDependecy, acima exempli�cada. Assim se R1
exclui R2, not hasDependecy(R1) = R2.
4.2 Modelo de Representação Gerado
O modelo inicialmente gerado prevê 19 classes (vide �gura 4.1) e 5 propriedades (sendo
4 destas Propriedades de Objeto e 1 Propriedade de Dado, vide tabela 4.1). Caracteri-
zando um ambiente que representas as especi�cidades de documentação de requisitos em
SPL.
O modelo proposto representa as singularidades de requisitos em SPL e através da
aplicação das regras de mapeamento neste trabalho elaboradas (subseção 4.1.6), consegue
especi�car requisitos de uma linha a ser desenvolvida (exempli�camos este fato no capítulo
5).
25
Capítulo 5
Utilização de Ontologias para
Requisitos
Neste capítulo apresentamos aplicações da Ontologia apresentada no capítulo 4 à Re-
quisitos em SPL, sendo estes mapeados para o formalismo adotado e posteriormente
validado pela aplicação de um provador automático de teorema em DL (Neste trabalho
optamos pelo provador HermiT1 visto sua instalação prévia na versão 4.1 do software
Protégé, sendo esta a versão mais recente do sistema durante a execução deste trabalho).
Introduziremos erros de coerência na documentação, a�m de simular situações onde tais
erros de elicitação de requisitos poderiam afetar o desenvolvimento do sistema.
Para melhor organização deste capítulo, cada seção aborda um tipo de erro distinto
dentro de um mesmo domínio de desenvolvimento, apresentado em detalhes na seção 5.1.
5.1 Descrição do Domínio Abordado
Para exempli�car a viabilidade de utilização de métodos de formalização de requisitos
SPL em Ontologia, apresentaremos um sistema (�ctício) para o domínio de submissão de
artigos à eventos acadêmicos. Partiremos dos seguintes objetivos2:
1. Possibilitar a autores;
2. Auxiliar no processo de gerência de avaliação de trabalhos;
3. Possibilitar ao cliente a customização do tipo de trabalho a ser aceito: Artigo Com-
pleto, Artigo Resumido e ambos podendo ou não ser encaminhados com Abstract;
1http://hermit-reasoner.com/2Deixamos claro que, os pontos aqui propostos não alcançam em abrangência o ramo de mercado
adotado, mas, se tornam su�cientes para esboçar nosso interesse de expor a viabilidade de se formalizar
requisitos de SPL em Ontologia
26
4. Expor ao cliente (Organizador) a opção da criação de um usuário que coordene o
comitê cientí�co (Coordenador);
5. Viabilidade de se incluir mecanismo de busca de trabalhos ao evento.
Com estes objetivos abstrai-se requisitos que atendam o mercado proposto. Analisando
o ponto 1, de�nem-se o requisito de submeter artigo e a existência do usuário Autor.
Com o ponto 2 propõem-se a de�nição de um componente de avaliação de trabalho, e a
existência de um outro usuário (Avaliador).
Esquematizando o objetivo 3, distingue-se o primeiro VP do sistema, o tipo de artigo
aceito. Este pode ser composto por Artigo Completo com ou sem Abstract, Artigo Re-
sumido com ou sem Abstract ou ambos. Ressaltando que a submissão de trabalhos por
um autor deve também, tratar essa variabilidade no sistema.
De�ne-se a existência de mais dois usuários no sistema, Organizador que organiza e se
responsabiliza pelo evento, e Coordenador que caracteriza-se como opcional e destina-se na
coordenação do comitê cientí�co. Por �m, os mecanismos de busca de trabalhos também
são opcionais, podendo estes serem executados através da busca por: Área, Conteúdo e
Palavras chave.
5.2 Incoerência em Especi�cação do Tipo de Dados
Nesta seção, apresentaremos uma possível inconsistência na elicitação de requisitos
quanto a especi�cação do tipo de dado a ser utilizado. Para tal propósito, partiremos da
especi�cação de que o sistema aqui adotado permite a realização de buscas.
Tais buscas recebem como entrada uma lista de argumentos, podendo ser executadas
de três formas (sendo possível a utilização em conjunto): Por área de atuação do artigo,
pelo conteúdo e por palavras chaves. Assim sendo, especi�camos um VP (PesquisarAr-
tigo) com suas respectivas Variantes (Area, Conteudo e PalavraChave).
Para representar que as buscas recebem como entrada uma lista de argumentos,
de�niu-se uma Propriedade de Objeto denominada hasSearchKey (tem Chave de Busca).
Exempli�caremos uma inconsistência utilizando esta propriedade, expondo que as buscas
devem ter como entrada uma lista, porém, a realização por palavras chave será do tipo
String, apresentamos este ambiente na tabela 5.1.
Tal especi�cação constitui-se com um erro, onde o VP (classe mais geral) PesquisarAr-
tigo delega que o tipo de dado a ser utilizado é um lista, logo em seguida documenta-se
que a forma de pesquisa por Palavra Chave deve ser realizada por uma String.
Esta incoerência foi apontada com a utilização do provador automático, apresentamos
então nas �guras 5.1 e 5.2, o modelo grá�co da Ontologia, antes da utilização do provador
27
Tabela 5.1: Especi�cação das propriedades de pesquisar artigos.
Requisito Tipo hasSearchKey
PesquisarArtigo VP List
Area V List
Conteudo V List
PalavraChave V String
e depois respectivamente. Apresentamos no Apêndice A a legenda de símbolos utilizados
em nossa explicação.
Figura 5.1: Especi�cação da característica de pesquisar artigos.
Figura 5.2: Provador automático na especi�cação de pesquisar artigos.
A distinção entre tais �guras esta que, o conceito PalavraChave não é mais represen-
tado como sub-classe de PesquisarArtigo (�gura 5.2), onde o software de prova encontra
uma incoerência em sua designação que fere as regras regidas pelo VP PesquisarArtigo.
5.3 Incoerência em especi�cação valorada
De�ne-se como especi�cação valorada para nosso trabalho, alguma determinação para
especi�car um requisito no qual se usa um valor especí�co dentro de um domínio. Ex.:
valor inteiro 1, valor texto �sou um requisito�, dentre outros.
Utilizando a especi�cação de um usuário para o sistema proposto, onde o campo
Senha deve possuir uma quantidade mínima e máxima de caracteres igual à 6 e 20 res-
pectivamente. Para tal representação cria-se duas propriedades de dados, hasMinSenha e
hasMaxSenha especi�cando a quantidade miníma e máxima de caracteres que podem ser
utilizados para cadastro de usuários.
28
Para representação destas propriedades, como domínio empregou-se classe Usuario, e
para contra-domínio o tipo de dado integer. Adotaremos que Usuario foi representando
com os valores especi�cados para o tamanho da senha, porém, (inserindo uma inconsistên-
cia) pontuou-se o Gerente com tamanho mínimo da senha igual a 10.
Assim sendo temo o ambiente de propriedades apontados na tabela 5.3:
Tabela 5.2: Especi�cação das propriedades dos usuários.
hasName hasSenha hasMinSenha hasMaxSenha
Usuario(VP) String String 6 20
Autor(V) String String 6 20
Avaliador(V) String String 6 20
Gerente(V) String String 10 20
Tal organização das propriedades apresenta uma inconsistência, onde o V (Gerente)
não se submete a todas as considerações impostas pelo seu VP (Usuario). Apresentamos
na �gura 5.3 a taxonomia respeitando a especi�cação da documentação antes da utilização
de um provador automático.
Figura 5.3: Especi�cação de usuários do sistema.
Após o emprego do provador automático de teorema, constatou-se a incoerência das
informações representadas, fazendo com que, a classe Gerente não seja mais determinada
como sub-classe do conceito Usuario e assim obstruindo a relação de V e VP existente. A
saída do provador automático é apresentada na �gura 5.4, sendo esta já traduzida para
um grafo.
5.4 Incoerência na Especi�cação de Dependência e Ex-
clusão
Utilizando-se da de�nição do requisito Submeter Artigo, que necessita do componente
Artigo em sua composição. Aplicaremos uma espécie de empasse, onde seguiremos os
29
Figura 5.4: Aplicação do provador automático na especi�cação de usuários do sistema.
objetivos dos domínio do software abordado, de�nindo a dependência de SubmeterArtigo
com Artigo.
Porém em uma das variações do conceito que especi�ca a submissão de artigos,
adotaremos que este V (SubmeterAbstract) possui uma relação de exclusão com a classe
Artigo.
Apresentamos na tabela 5.3 o conjunto de propriedades de�nidas para este fragmento
do sistema, englobando também a propriedade hasDependecy.
Tabela 5.3: Especi�cação das dependências do componente Submeter Artigo.
Componente hasDependecy
SubmeterArtigo Artigo
SubmeterAbastract not Artigo
SubmeterCompleto Artigo
SubmeterResumo Artigo
Figura 5.5: Especi�cação de como o sistema trata submissão de artigos.
Figura 5.6: Aplicação do provador automático na especi�cação de submissão de artigos.
Apresentamos com as �guras 5.5 e 5.6 respectivamente a representação em grafo da
Ontologia, antes da prova (representa a especi�cação como foi inserida) e após utilização
do provador automático.
30
Capítulo 6
Conclusão
6.1 Resultados
Neste trabalho apresentamos um modelo em Ontologia para representação de requisi-
tos em Linha de Produto de Software, tal representação aborda aspectos característicos à
documentação de requisitos em SPL, servindo de alicerce para receber especi�cações de
requisitos de sistemas a serem desenvolvidos.
Para atender tal objetivo de documentar especi�cações de sistemas, apresentou-se no
capítulo 4 as regras de mapeamento da etapa de elicitação para Ontologia, que apresentam
a forma em que determinado requisito deve ser representado no formalismo desenvolvido.
As regras e formalização compiladas foram alcançadas com a metodologia apresentada
no capítulo 4, tal abordagem pautou-se nas etapas de especi�cação de conhecimento do
proposto por Noy e McGuinness (2009), juntamente com os conceitos de Engenharia de
Conhecimento abordados em Brachman (2004).
A metodologia utilizada neste trabalho se resume em uma adaptação aos métodos
utilizados pelas referências do parágrafo supracitado, sendo alterada para encaixar-se
mais adequadamente ao domínio utilizado, documentação de requisitos em SPL e aos
objetivos propostos.
A�m de apresentar a viabilidade de formalização dos processos de documentação e
validação de requisitos de SPL para Ontologia, utilizou-se do capítulo 5 para exempli�car
a utilização do modelo desenvolvido, sendo este capítulo constituído de simulações de
erros de incoerência que podem ocorrer em documentações reais de sistemas.
Tal artifício foi utilizado para discorrer a possibilidade de encontrar erros na documen-
tação, através do emprego de provadores automáticos de teoremas em uma especi�cação
formal de requisitos em Ontologia, objetivando-se enfatizar a viabilidade de diminuição
investimentos empregados no desenvolvimento inicial de uma SPL.
Com tais resultados podemos expor que, a aplicação de formalismos de DL à docu-
31
mentação de requisitos em SPL, possibilita a aplicação de provadores automáticos de
teoremas os quais podem encontrar incoerência na elicitação, implicando possivelmente
na diminuição de custos futuros para correção e manutenção dos componentes devido à
incoerências nas fases iniciais de projeto, apontando também em [Nóbrega et al., 2010].
Tal aplicação auxilia também no processo de validação de requisitos, contribuindo de
certa forma para a compressão de gastos temporais e �nanceiros mais elevados, caracterís-
ticos da abordagem de desenvolvimento de software em SPL, �xado também na diminuição
do tempo de reposta de lucros desta forma de desenvolvimento (após a instanciação do
terceiro sistema [Pohl et al., 2005]).
Com o tema abordado neste trabalho tivemos as seguintes publicações em eventos:
1. Nóbrega, F. A. A. ; da Costa, V., G.; Lobato, L., L.;Aplicação de Lógica Descritiva
para Documentação e Validação de Requisitos em SPL. ENACOMP - Encontro
Anual de Computação, 2010, Catalão.
2. Nóbrega, F. A. A. ; da Costa, V., G.; Explicando Provas em Lógicas de Descrição.
Conpeex - Congresso de Pesquisa, Ensino e Extensão, 2010, Goiânia.
3. Andrade H. S., Nóbrega F. A. A., Pedrosa L. R., dos Santos M. R.,Cardoso D. M.
S, de Almeida G. A., Lobato, L. L; Benefícios e desa�os no desenvolvimento de
software: A abordagem SPL. SEPEC - Simpósio de Ensino, Pesquisa, Extensão e
Cultura, 2009, Catalão.
Sendo os artigos 2 e 3 com temas relacionados a este trabalho, e o artigo 1 sendo
produto desta pesquisa.
6.2 Trabalhos Futuros
Apresentaremos nesta seção os trabalhos que visamos iniciar e/ou concluir futura-
mente, tais propostas baseiam-se nos resultados não alcançados neste trabalho (ou para
enfatizar os resultados aqui encontrados), melhorias quanto a utilização do formalismo
desenvolvido e buscar densi�car a utilização deste mecanismo visando a comunidade de
engenharia de software. Assim propomos:
1. Melhorar os mecanismos de explicação automática de prova: O mecanismo aqui
utilizado foi a utilização da geração de grafos, que representam a taxonomia dos
conceitos representados, propomos futuramente utilizar-se de mecanismos grá�cos
da UML e modelo Ortogonal para expor os resultados da especi�cação, como por
exemplo gerar diagramas de classes ou de variabilidade, os quais são mecanismos de
linguagens mais habituais ao público mais presente nos ambiente de desenvolvimento
de softwares;
32
2. Gerar tradutor XML para OWL: Devido a existência de formas de documentação de
requisitos de uma SPL em formato XML, propomos futuramente o desenvolvimento
de softwares que traduzam tal formato de documentação para OWL, poupando
tempo de re-documentação não formal para formal, e auxiliando a migração das
documentações já existentes nas empresas;
3. Gerar tradutor Linguagem Natural para OWL: No trabalho apresentado por Silva
et al. (2007), mostrou-se possível a geração de Ontologias tomando como fonte
arquivos em Linguagem Natural, de forma automática com ferramentas computa-
cionais. Assim sendo, propomos implementação de programa semelhante que dada
um entrada em linguagem natural, composta pela especi�cação de algum sistema,
seja gerada de forma automática (ou semiautomática) uma Ontologia equivalente
que representa tal especi�cação;
4. Comparação entre formas de documentação: Propomos a comparação deste método
de documentação (formalização de requisitos em Ontologias) com outros abordagens
mais corriqueiros de elicitação, a�m de, apresentar valores mais concretos quanto às
vantagens e/ou desvantagens da formalização de requisitos em SPL;
6.3 Di�culdades Encontradas
Apresentaremos nesta seção as di�culdades encontradas durante a execução deste tra-
balho, abordando também as justi�cativas para adiar alguns objetivos deste.
O software Protégé, utilizado para facilitar a geração de Ontologias, possui mecanismos
que possibilitam a geração de plugins, que utilizando sua arquitetura possam agregar
funcionalidades ao sistema.
A geração de algumas ferramentas computacionais apontadas como trabalho futuros
(tradutores automáticos XML para OWL e linguagem natural para OWL), utilizariam
deste recurso para serem implementados, sendo que, para tal desenvolvimento necessita-se
o conhecimento da arquitetura que especi�ca o sistema Protégé 1.
A documentação que especi�ca a arquitetura desta ferramenta, apresenta detalhes de
versões mais antigas do sistema, não sendo completa para os objetivos dos componentes
a serem desenvolvidos. Caracterizando-se assim como uma di�culdade para o conclusão
da implementação destes plugins.
1O software em questão é desenvolvido em linguagem Java, sendo seus respectivos plugins construindo
em mesma linguagem, ou outra que possa se comunicar com tal
33
Referências
Baader, F., Calvanese, D., McGuinness, D., Nardi, D., e Patel-Schneider, P. (2003). The
Description Logic Handbook. Cambridge University Press.
Bechhofer, S., van Harmelen, F., Hendler, J., Horrocks, I., McGuiness, D. L., Patel-
Schneider, P., e Stein, L. A. (2009). Owl web ontology language. In W3C Recommen-
dation.
Birk, A. e Heller, G. (2007). Challenges for requirements engineering and management in
software are product line development. REFSQ 2007, 1.
Brachman, R. J. e Levesque, H. J. (2004). Knowledge Representation and Reasoning.
Elsevier.
Bueno, F. (1996). Minidicionário da Língua Portuguesa. FTD.
Gruber, T. R. (1993). Toward principles for the design of ontologies used for knowledge
sharing. In Formal Ontology in Conceptual Analysis and Knowledge Representation.
Horridge, M., Knublauch, H., Rector, A., Stevens, R., e Wroe, C. (2004). A Prac-
tical Guide To Building OWL Ontologies Using The Protégé-OWL Plugin and CO-
ODETools. University Of Manchester, 1 edition.
Mcguinnes, D. e Borgida, A. (1995). Explaining subsumption in description logics. In
Proc. of the 14th International Joint Conference on Arti�cial Intelligence.
Moura, V. (2001). Especi�cações em z: uma introdução. Technical report, Unicamp.
Nardi, J. C. e de Almeida Falbo, R. (2006). Uma ontologia de requisitos de software.
Technical report, Universidade Federal do Espírito Santo � ES � Brasil.
Nóbrega, F. A., da Costa, V. G., e Lobato, L. L. (2010). Aplicação de lógica descritiva
para documentação e validação de requisitos em spl. ENACOMP � Encontro Anual de
Computação, 1.
Neiva, D. F. S. (2009). Riple�re: A requirements engineering process for software pro-
ductlines. Technical report, Universidade Federal de Pernambuco � PE � Brasil.
Noy, N. F. e McGuiness, D. L. (2009). Ontology development
101: A guide to creating your �rst ontology. Disponível em:
http://www.cs.man.ac.uk/carole/old/GGF/20Tutorial/20Stu�/ontology101.pdf. Stan-
ford University, Stanford, CA, USA.Acessado em: Novembro 2010.
34
Paul, C. e Linda, N. (2001). Software product lines: practices and patterns. Addison-
Wesley Longman Publishing Co., Inc., Boston, MA, USA, 3 edition.
Pohl, K., Böckle, G., e van der Linden, F. (2005). Software Product Line Engineering.
Springer.
35
Apêndice A
Legenda
Imagem Signi�cado
Representa classes que possuem especi�cação no campo de classe de
equivalência, em nosso contexto são classes que caraterizam VP
Representa classes que não possuem especi�cação no campo de classe
de equivalência, em nosso contexto são classes que caracterizam Vs ou
requisitos normais
Utilizado pelo Protégé pra informar que o conceito pode ser expandido,
ou seja, possui mais classes do que as visualizadas na imagem
Representa uma condição de hierarquia (subclasse), sendo a classe mais
genérica (Pai) inserido ao lado esquerdo (seta branca) e a classe mais
especí�ca (�lho) do lado esquerdo
36