Maria Lúcia Bento Villela
Validação de Diagramas de Classe por meio de
Propriedades Ontológicas
Dissertação apresentada ao Curso de
Pós-Graduação em Ciência da Computação da
Universidade Federal de Minas Gerais, como
requisito parcial para a obtenção do grau de
Mestre em Ciência da Computação.
Belo Horizonte - MG
Junho de 2004
Ao meu esposo Severino Delmar Junqueira Villela e aos meus filhos Amaury e Luiza, com todo o meu amor e minha gratidão.
AGRADECIMENTOS
A Deus, que iluminou meu caminho e me permitiu realizar este sonho.
Ao meu esposo Severino, cujo incentivo, carinho e compreensão foram imprescindíveis para esta conquista.
Aos meus filhos Amaury e Luiza, que mesmo sentindo minha ausência e sem poderem entender o motivo, me deram grande força através do carinho e amor que sempre me dedicaram durante este período do Mestrado.
Aos meus pais, Geraldo e Consolação, pelo apoio e pelos bens mais valiosos a mim transmitidos: a educação e a honestidade.
Aos meus irmãos, Marcos, Márcia e Mônica, pelo apoio e carinho.
Aos pais do meu esposo, Amaury e Edméa, e aos meus cunhados, em especial à Elizete, pelo apoio, pela amizade e pela ajuda com as crianças.
Ao Departamento de Informática da Universidade Federal de Viçosa e ao Departamento de Ciência da Computação da Universidade Federal de Minas Gerais, pela oportunidade de realização deste curso.
Ao professor Alcione de Paiva Oliveira, pela orientação, pelos ensinamentos e pela amizade dispensados ao longo do curso.
Aos professores José Luís Braga, Clarindo Isaías Pereira da Silva e Pádua e Maria Luiza D´Almeida Sanchez, pelas valiosas sugestões para a conclusão deste trabalho.
Aos professores do Departamento de Informática, pelos conhecimentos transmitidos.
Aos amigos e colegas do Mestrado, pela amizade, paciência e principalmente pela oportunidade de convivência.
A todas as pessoas que direta ou indiretamente contribuíram para a realização deste trabalho.
ABSTRACT
The conceptual modeling is a fundamental step in the systems development activity, because it is through it the relevant concepts of the domain are captured, allowing its incorporation in an information system. However, in order to obtain a conceptual model that is an adequate description of the problem domain, it is necessary to have a clear understanding of the domain, gained from a detailed analysis of the domain objects properties. Such analysis, called ontological analysis, can be used as source of knowledge for conceptual modelers, making possible to minimize the occurrence of semantic errors in its models. This work surveys the use of ontological knowledge, as a tool for the conceptual modeling task for attaining quality conceptual models, that reflects correct the domain reality. To show the applicability of ontological knowledge in conceptual modeling of systems, one technique, called VERONTO (VERificação ONTOlógica) was developed. It considers the use of ontological meta-properties for validation of conceptual models expressed by means of UML class diagrams. The use of such meta-properties allowed the development of clearer conceptual models, without ambiguities, nor redundant information, facilitating, in this way, the development, the maintenance and the integration of information systems.
RESUMO
A modelagem conceitual consiste numa atividade importante no projeto de sistemas, pois é a partir dela que se obtém abstração e estruturação dos conceitos abstraídos de um domínio do mundo real, permitindo sua incorporação em um sistema de informação. Porém, para que a modelagem conceitual possa ser uma descrição adequada da realidade do domínio do problema, ela deve apresentar informações precisas e claras, que podem ser obtidas a partir de uma análise mais detalhada das propriedades dos objetos de um domínio. Tal análise, denominada análise ontológica, pode ser utilizada como fonte de conhecimento para modeladores conceituais, possibilitando minimizar a ocorrência de erros semânticos em seus modelos. Este trabalho mostra que o uso de conhecimento ontológico, como suporte para a tarefa de modelagem conceitual, pode contribuir para a obtenção de modelos conceituais de qualidade, que expressem de forma correta a realidade do domínio. Para mostrar a aplicabilidade de ontologia em modelagem conceitual de sistemas, foi desenvolvida uma técnica, denominada VERONTO (VERificação ONTOlógica), que propõe o uso de meta-propriedades ontológicas para validação de modelos conceituais expressos por meio de diagramas de classe da UML. O uso de tais meta-propriedades permitiu o desenvolvimento de modelos conceituais mais claros, sem ambigüidades, nem informações redundantes, facilitando, dessa forma, o desenvolvimento, a manutenção e a integração de sistemas de informação.
ÍNDICE
1. INTRODUÇÃO... 1
2. MODELAGEM CONCEITUAL UTILIZANDO DIAGRAMAS DE CLASSES EM UML... 4
2.1. NOÇÕES BÁSICAS... 4
2.2. MODELAGEM CONCEITUAL ORIENTADA A OBJETOS... 5
2.2.1. O Paradigma de Orientação a Objetos ... 5
2.2.2. A UML ... 6 2.2.3. Diagrama de Classes ... 7 2.2.3.1. Tipos de Relacionamentos... 8 2.2.3.1.2.1. AGREGAÇÃO COMPARTILHADA... 10 2.2.3.1.2.2. COMPOSIÇÃO... 10 2.2.3.1.3.1. GENERALIZAÇÃO RESTRITA... 14
3. O USO DE ONTOLOGIAS PARA MODELAGEM CONCEITUAL DE SISTEMAS... 16
3.1. ONTOLOGIA... 16
3.2. ONTOLOGIAS FORMAIS... 21
3.2.1. Ontologias de Nível Topo ... 21
3.2.2. Ontologias de Domínio ... 23
3.3. FUNDAMENTOS ONTOLÓGICOS DE MODELAGEM CONCEITUAL... 23
3.3.1. Ontologias de Nível Topo Como Ferramentas de Análise de Modelos Conceituais ... 23
3.3.2. Criação e Utilização de Ontologias de Domínio como Base para Modelagem Conceitual... 31
4. ANÁLISE CONCEITUAL ORIENTADA POR ONTOLOGIA ... 34
4.1. ONTOLOGIA DE PROPRIEDADES... 34
4.1.1. Noções Básicas... 34
4.1.2. Ferramentas Formais de Análise Ontológica ... 36
4.1.2.1. Rigidez ... 36
4.1.2.2. Dependência ... 37
4.1.2.3. Identidade... 38
4.1.2.4. Unidade ... 39
4.1.3. Restrições Taxonômicas ... 40
4.1.3.1. Restrições sobre Rigidez ... 40
4.1.3.2. Restrições sobre Identidade ... 40
4.1.3.3. Restrições sobre Dependência... 41
4.1.3.4. Restrições sobre Unidade... 41
4.1.4. Princípios considerando Identidade... 41
4.3. TIPOS DE PROPRIEDADES... 43 4.3.1. Categorias ... 44 4.3.2. Tipos ... 44 4.3.3. Quase-Tipos... 45 4.3.4. Papéis Formais ... 45 4.3.5. Papéis Materiais ... 46
4.3.6. Sortais com Fases... 46
4.3.7. Atribuições... 47
4.3.8. Mixins ... 47
5. VERONTO: UMA PROPOSTA DE UTILIZAÇÃO DAS META-PROPRIEDADES E REGRAS BASEADAS EM ESTUDOS ONTOLÓGICOS FORMAIS NO APOIO À MODELAGEM CONCEITUAL ... 48
5.1. MAPEAMENTO DAS CLASSIFICAÇÕES DE PROPRIEDADES EM ELEMENTOS DO DIAGRAMA DE CLASSES DA UML ... 49
5.1.1. Mapeamento da Classificação de Propriedade “Tipo” para Construtor de Diagrama de Classes da UML... 50
5.1.2. Mapeamento da Classificação de Propriedade “Quase-Tipo” para Construtor de Diagrama de Classes da UML... 50
5.1.3. Mapeamento da Classificação de Propriedade “Papel Material” para Construtor de Diagrama de Classes da UML.... 52
5.1.4. Mapeamento da Classificação de Propriedade “Sortal com Fases” para Construtor de Diagrama de Classes da UML... 53
5.1.5. Mapeamento da Classificação de Propriedade “Mixin” para Construtor de Diagrama de Classes da UML... 54
5.1.6. Mapeamento da Classificação de Propriedade “Categoria” para Construtor de Diagrama de Classes da UML... 55
5.1.7. Mapeamento da Classificação de Propriedade “Papel Formal” para Construtor de Diagrama de Classes da UML... 56
5.1.8. Mapeamento da Classificação de Propriedade “Atribuição” para Construtor de Diagrama de Classes da UML... 57
5.2. ADIÇÃO DE REGRAS PARA USO DE RELACIONAMENTOS EM MODELAGEM CONCEITUAL,BASEADAS EM ESTUDOS ONTOLÓGICOS FORMAIS... 59
5.2.1. Regras para Relacionamentos Opcionais... 60
5.2.2. Regras para Agregação... 60
5.3. APLICAÇÃO DA TÉCNICA VERONTO... 60
6. ESTUDO DE CASO... 62
6.1. DOMÍNIO DE LIVRARIAS ELETRÔNICAS... 62
6.1.1. Atribuição das Meta-propriedades às Classes do Domínio... 64
6.1.1.1. Cliente ... 64
6.1.1.2. Cliente Brasil ... 64
6.1.1.3. Endereço ... 65
6.1.1.4. Endereço de Entrega ... 66
6.1.1.6. Vale Desconto... 67
6.1.1.7. Cartão de Crédito... 68
6.1.1.8. Perfil ... 68
6.1.1.9. Área de Interesse... 69
6.1.1.10. Lista de Presentes ... 70
6.1.1.11. Item de Lista de Presentes ... 70
6.1.1.12. Livro... 71 6.1.1.13. Seção ... 72 6.1.1.14. Autor... 72 6.1.1.15. Editora ... 73 6.1.1.16. Resenha ... 73 6.1.1.17. Resenha Leitor ... 74 6.1.1.18. Resenha Editorial... 74 6.1.1.19. Pedido ... 75 6.1.1.20. Log de Pedido ... 76 6.1.1.21. Item de Pedido ... 76 6.1.1.22. Pagamento ... 77
6.1.1.23. Pagamento Cartão de Crédito ... 78
6.1.1.24. Pagamento Boleto Bancário ... 78
6.1.1.25. Pagamento Transferência Eletrônica... 79
6.1.2. Verificação das Restrições Impostas sobre Relacionamentos Taxonômicos, como Conseqüência das Meta-Propriedades Atribuídas a seus Argumentos... 82
6.1.3. Verificação de Propriedades e Relacionamentos Hierárquicos Ausentes ... 82
6.1.4. Aplicação das Regras para Uso de Relacionamentos Sugeridas por WAND et al. (1999) ... 83
6.2. DOMÍNIO DE GERENCIAMENTO DE EVENTOS... 86
6.2.1. Atribuição das Meta-propriedades às Classes do Domínio... 87
6.2.1.1. Usuário ... 87 6.2.1.2. Participante ... 88 6.2.1.3. Patrocinador ... 88 6.2.1.4. Palestrante ... 89 6.2.1.5. Funcionário... 90 6.2.1.6. Locatário... 90 6.2.1.7. Serviço Terceirizado ... 91 6.2.1.8. Equipamento ... 92 6.2.1.9. Evento ... 92 6.2.1.10. Stand ... 93 6.2.1.11. Atividade... 93
6.2.2. Verificação das Restrições Impostas sobre Relacionamentos Taxonômicos, como Conseqüência das Meta-Propriedades Atribuídas a seus Argumentos... 94
6.2.3. Verificação de Propriedades e Relacionamentos Hierárquicos Ausentes ... 95
6.2.4. Aplicação das Regras para Uso de Relacionamentos Sugeridas por WAND et al. (1999) ... 95
7. ANÁLISE DOS RESULTADOS... 98
8. CONCLUSÕES E TRABALHOS FUTUROS... 100
LISTA DE FIGURAS
Figura 2.1 – (a) Representação da classe Cliente em UML, exibindo os seus atributos e operações. (b) Representação da classe Cliente em UML, exibindo apenas os seus atributos. (c) Representação da classe Cliente em UML, não exibindo seus atributos e nem suas
operações. ...8
Figura 2.2 – Associação Leciona entre as classes Professor e Disciplina. ...9
Figura 2.3 – Associação Fornece com suas multiplicidades e o papel da classe Empresa definidos. ...9
Figura 2.4 – Exemplo de agregação compartilhada, envolvendo a classe “parte” Funcionário e a classe “todo” Equipe. ...10
Figura 2.5– Exemplo de composição, envolvendo as classes “partes” Informação, Botão Cancelar e Botão OK e a classe “todo” Caixa de Mensagem. ...11
Figura 2.6 – Exemplo de relacionamento de Generalização, com as subclasses Carro, Barco e Avião herdando as características da superclasse Veículo....13
Figura 2.7– Exemplo de relacionamento de Generalização, com uma hierarquia de classes. A classe Carro é uma subclasse de Veículo e ao mesmo tempo superclasse de Carro de Passeio e Utilitário. ...13
Figura 2.8 – Exemplo de Generalização com a superclasse abstrata Pagamento...14
Figura 2.9 – Exemplo de uma Generalização de Sobreposição...15
Figura 2.10 – Exemplo de uma Generalização Completa. ...15
Figura 3.1 – Exemplo de composição com parte inseparável e essencial. Fonte: GUIZZARDI et al. (2002b)...25
Figura 3.2 - O mesmo indivíduo pesquisador participando de diferentes relações todo-parte contextual. Fonte: GUIZZARDI et al. (2002b)...26
Figura 3.3 – Utilização de um relacionamento opcional. ...29
Figura 3.4 – Estudante e Livro adquirem uma propriedade mútua – Toma emprestado. Fonte: WAND et al. (1999). ...29
Figura 3.5 – Utilização de subtipos participando de relacionamentos “parte-de” obrigatórios. Fonte: WAND et al. (1999). ...30
Figura 5.1 – Exemplo de classe correspondente a um Quase-Tipo. ...51
Figura 5.2 – Exemplo de classes correspondentes a Papéis Materiais...53
Figura 5.3 – Exemplo de classes correspondentes a Sortais com Fases...54
Figura 5.4 – Exemplo de classe correspondente a Mixin. ...55
Figura 5.6 – Exemplo de classe correspondente a Papel Formal. ...57 Figura 5.7 – Fluxo de aplicação da técnica VERONTO...61 Figura 6.1 – Diagrama de Classes de um Domínio de Livrarias Eletrônicas.
Fonte: MONTEIRO (2002). ...63 Figura 6.2 – Diagrama de Classes do Domínio de Livrarias Eletrônicas com as
Meta-Propriedades atribuídas às Classes...81 Figura 6.3 – Diagrama de Classes do Domínio de Livrarias Eletrônicas Validado. ..85 Figura 6.4 – Diagrama de Classes de um Domínio de Gerenciamento de
Eventos. Fonte: TOLEDO et al. (2003). ...87 Figura 6.5 – Diagrama de Classes do Domínio de Gerenciamento de Eventos
com as Meta-Propriedades atribuídas às Classes ...94 Figura 6.6 – Diagrama de Classes do Domínio de Gerenciamento de Eventos
Validado ...97
LISTA DE TABELAS
Tabela 3.1 – Especificação explícita de uma conceitualização. Fonte: MOREIRA (2003)...18 Tabela 4.1 - Propriedades formadas a partir da combinação das
meta-propriedades. Adaptada de GUARINO e WELTY (2000a)...43 Tabela 5.1 - Associação dos tipos de propriedades definidos por GUARINO e
WELTY (2000a) aos construtores de modelagem conceitual UML...58 Tabela 5.2 - Associação das meta-propriedades relacionadas a unidade e
identidade aos construtores de modelagem conceitual UML, e as restrições que essas impõem a relacionamentos “parte-todo”...59
1. INTRODUÇÃO
A modelagem conceitual consiste numa atividade importante no projeto de sistemas, pois é a partir dela que se obtém abstração e estruturação do conhecimento sobre um domínio do mundo real, permitindo sua incorporação em um sistema de informação.
O objetivo da modelagem conceitual é construir uma representação de alta qualidade de um fenômeno selecionado em algum domínio. Modelos conceituais resultantes devem facilitar o projeto, implementação, operação e manutenção de sistemas de informação. Como as atividades de modelagem conceitual ocorrem normalmente durante as fases iniciais do processo de desenvolvimento de sistemas, erros e omissões de modelagem que não forem detectados inicialmente podem ter repercussões custosas. Dessa forma, o aprimoramento das metodologias que guiam a construção da modelagem conceitual é de suma importância.
Para que a modelagem conceitual possa ser uma descrição adequada da realidade do domínio do problema, ela deve apresentar informações precisas e claras, não permitindo a ocorrência de ambigüidades sobre os aspectos que devem ser modelados.
Porém, nem sempre os profissionais responsáveis pela tarefa de modelagem possuem um conhecimento claro sobre a natureza dos objetos e conceitos pertencentes ao domínio e termos que o denotam, o que pode levar a modelos conceituais apresentando falhas sob o aspecto semântico, como duplicação de informação e hierarquias espúrias.
A duplicação de informação ocorre quando um conceito, que deveria ser modelado como uma entidade separada, é incorporado em duas ou mais entidades distintas. Por exemplo, num domínio acadêmico de uma Instituição de Ensino, onde funcionários também podem ser estudantes, um determinado funcionário que também é estudante da Instituição vai aparecer como instância da entidade funcionário e da entidade estudante, com suas informações pessoais presentes em ambas as entidades. Já o caso de hierarquias espúrias ocorre quando o relacionamento hierárquico entre entidades do domínio é
utilizado de forma incorreta, muitas vezes sendo confundido com outros tipos de relacionamento, como instanciação, agregação ou constituição (GUARINO e WELTY, 2002). Um exemplo seria um relacionamento hierárquico entre as entidades Oceano e Água, com esta última subjugando a primeira. Apesar de, à primeira vista, parecer que Oceano seja um subgrupo de Água, ao se fazer uma análise detalhada da natureza destas entidades, conclui-se que tal relacionamento é incorreto, uma vez que, na realidade, Oceano é constituído de Água.
Uma análise mais detalhada das propriedades dos objetos de um domínio, denominada de análise ontológica, pode ser utilizada como fonte de conhecimento para modeladores conceituais, possibilitando minimizar esses erros.
A ontologia é um ramo da filosofia que estuda a organização e a natureza do mundo (GUARINO, 1995). Na computação e, particularmente na sub-área de representação do conhecimento, o termo ontologia tem sido utilizado para denotar o registro das descrições dos conceitos e suas relações abstraídas de um domínio. MOREIRA (2003) apresenta um estudo detalhado sobre as diferenças entre o significado do termo na computação e na filosofia.
Existem, na literatura, diversos trabalhos que relacionam ontologias e modelagem conceitual, seguindo basicamente duas linhas distintas. A primeira utiliza modelos ontológicos como ferramentas de validação de elementos de modelagem conceitual, no sentido de fornecer uma definição precisa dos mesmos e, conseqüentemente, obter modelos conceituais com uma semântica clara e bem definida (GUIZZARDI et al., 2002a; GUIZZARDI et al., 2002b; RABAN e GARNER, 2001; WAND et al., 1999). A segunda linha utiliza ontologias específicas de domínio como uma ferramenta de apoio à tarefa de modelagem conceitual, consistindo numa etapa anterior a esta e utilizada para a captura de conhecimento do mundo real sobre o domínio a ser modelado (STOREY et al., 1998; SUGUMARAN e STOREY, 2002). No entanto, ainda faltam propostas que mostrem como adequar a modelagem ontológica às linguagens e processos de especificação de software.
meta-2000b), e as restrições sobre relacionamentos hierárquicos por elas impostas, para validação de modelos conceituais expressos por meio de diagramas de classe, buscando uma forma de relacionar racionalmente ontologia e modelagem conceitual.
A contribuição principal deste trabalho consiste em apresentar um mapeamento das classificações de propriedades apresentadas por GUARINO e WELTY (2000a), geradas a partir de combinações das meta-propriedades, e das restrições que estas impõem sobre relacionamentos hierárquicos, nos elementos do diagrama de classes da UML. Espera-se que o uso destas restrições permita a construção de modelos conceituais mais manuteníveis e flexíveis. A aplicação destas meta-propriedades aos elementos do domínio exige que seja realizada uma análise ontológica dos mesmos. Dessa forma, este trabalho propõe a introdução de uma etapa adicional no processo de desenvolvimento de software, que consiste na verificação do modelo conceitual a partir de uma análise ontológica dos elementos do domínio, sendo denominada VERONTO (VERficação ONTOlógica).
A apresentação desta dissertação ocorre da seguinte forma: o capítulo 2 apresenta uma revisão de literatura sobre modelagem conceitual e diagramas de classe da UML. No capítulo 3 é realizada uma breve discussão sobre ontologias, buscando mostrar as características de uma ontologia a ser utilizada na modelagem conceitual. São mostradas também algumas pesquisas desenvolvidas nesta área. No capítulo 4, são descritos, com alguns detalhes, aspectos da análise conceitual orientada a ontologia. No capítulo 5 é apresentada a técnica VERONTO, a partir do uso das meta-propriedades apresentadas por GUARINO e WELTY (2000a, 2000b) e das regras baseadas em estudos ontológicos formais, para validação de modelos conceituais expressos na forma de diagramas de classes. No capítulo 6 são mostrados exemplos, por meio de estudos de caso, de aplicação da técnica VERONTO em modelos conceituais de dois domínios diferentes. O capítulo 7 apresenta uma análise qualitativa dos resultados obtidos e, finalmente, o capítulo 8 mostra as conclusões obtidas a partir do presente trabalho e sugestões de trabalhos futuros.
2. MODELAGEM CONCEITUAL UTILIZANDO DIAGRAMAS DE
CLASSES EM UML
2.1. Noções Básicas
Em Engenharia de Software, um processo de desenvolvimento de software é normalmente constituído das fases de levantamento dos requisitos, análise dos requisitos, desenho do sistema, implementação e testes (ERIKSSON e PENKER, 1998; PAULA FILHO, 2001).
Após as exigências e necessidades dos usuários para o sistema terem sido levantadas, segue a fase de análise dos requisitos, onde é realizada a modelagem conceitual, através de abstrações dos elementos relevantes do domínio do problema, e também definidas as operações, correspondentes aos requisitos funcionais, que serão aplicadas sobre tais elementos. Esta fase do desenvolvimento do software focaliza os requisitos do sistema na visão dos desenvolvedores e, especificamente a parte relacionada à modelagem conceitual, é onde o presente trabalho se concentra.
Um modelo pode ser definido como a descrição de algo, utilizando-se normalmente uma linguagem visual; o que significa que a maior parte da informação contida nos modelos é expressa através de símbolos e conexões gráficas (ERIKSSON e PENKER, 1998). A utilização de modelos é útil em qualquer engenharia, pois a construção de um produto ocorre normalmente baseada em modelos previamente construídos, que descrevem a aparência e o comportamento do mesmo. Dessa forma, na engenharia de software, a construção de modelos de sistemas antes de implementá-los está se tornando bastante comum e aceita como o é em outras engenharias.
Segundo ELMASTRI e NAVATHE (2000), o modelo conceitual consiste em uma descrição concisa, utilizando-se uma linguagem de modelagem de alto nível, dos requisitos de dados coletados dos usuários, incluindo descrições detalhadas de tipos de dados, relacionamentos e restrições. ELMASTRI e NAVATHE (2000) apontam como vantagens da utilização de tais modelos, primeiramente que eles são mais fáceis de serem entendidos, uma vez que os conceitos ali presentes não incluem nenhum detalhe de implementação,
podendo ser utilizados para comunicação com usuários não técnicos; o modelo conceitual de alto nível também pode ser utilizado como referência para assegurar que todos os requisitos de dados do usuário foram alcançados e que não incluem quaisquer conflitos.
ERIKSSON e PENKER (1998) afirmam que a criação de modelos conceituais é uma tarefa altamente criativa, pois não existe uma solução final ou resposta correta que possa ser checada ao final do trabalho. A construção de um modelo se faz por meio de um trabalho interativo, com seus projetistas alcançando um conhecimento mais aprofundado do domínio do problema e buscando assegurar que o modelo em questão atinja os objetivos e requisitos do sistema e de seus usuários.
Em relação à qualidade de modelos conceituais, ainda ERIKSSON e PENKER (1998) afirmam que bons modelos devem capturar a essência do domínio do problema, além de serem consistentes, íntegros e de fácil entendimento e manutenção. Modelos também devem ser capazes de serem integrados, ou seja, deve ser possível unir, sem introduzir inconsistências, um conjunto de modelos que apresentam os mesmos propósitos e representem informações sobre o mesmo domínio.
2.2. Modelagem Conceitual Orientada a Objetos 2.2.1. O Paradigma de Orientação a Objetos
O paradigma de orientação a objetos consiste em uma tecnologia para produzir conceitos que refletem um domínio do mundo real, em uma maneira natural, utilizando a terminologia do domínio. Este paradigma surgiu com a finalidade de acelerar o processo de desenvolvimento de software, bem como produzi-lo de tal forma que não extrapole o orçamento inicialmente estipulado e que satisfaça as necessidades e exigências dos clientes. Sistemas construídos utilizando tecnologia de orientação a objetos possuem arquiteturas bem definidas, e fornecem a oportunidade para criar e implementar componentes reutilizáveis (ERIKSSON e PENKER, 1998).
Para se utilizar o paradigma de orientação a objetos de forma ampla e completa no processo de desenvolvimento de software, é necessário a utilização de uma linguagem de modelagem orientada a objetos que integre facilmente as fases de análise e desenho com técnicas e ferramentas de construção adequadas. Dessa forma, modelos orientados a objetos, quando construídos corretamente, além de apresentarem todas as características vistas anteriormente de um modelo de qualidade; podem ser naturalmente implementados em software, através da utilização de linguagens de programação orientadas a objetos (ERIKSSON e PENKER, 1998).
Em modelagem orientada a objetos, classes, objetos e relacionamentos são os elementos primários de modelagem. Classes representam entidades do domínio do problema que são manipulados no sistema. Os relacionamentos entre as classes revelam o comportamento de cada classe do domínio em relação a outras classes (ERIKSSON e PENKER, 1998). Uma Classe é uma descrição de um tipo Objeto. Objetos são instâncias de classes, que por sua vez descrevem as propriedades e o comportamento de um tipo de objeto.
2.2.2. A UML
A UML (Unified Modeling Language) (BOOCH et al., 1999; RUMBAUGH et al., 1999) consiste em uma linguagem de modelagem orientada a objetos, com todos os seus elementos e diagramas baseados no paradigma de orientação a objetos, que pode ser utilizada em diferentes fases do desenvolvimento do sistema, desde a especificação de requisitos até o teste de um sistema concluído (ERIKSSON e PENKER, 1998).
A UML tornou-se uma linguagem de modelagem orientada a objetos padrão, sendo amplamente utilizada na construção de modelos conceituais em métodos de desenvolvimento de software orientados a objetos, visando estabelecer uma ligação explícita entre elementos conceituais e elementos executáveis.
Dentre os processos de desenvolvimento de software que utilizam a UML como notação de modelagem, pode-se citar o RUP (Rational Unified
Process) (JACOBSON et al., 1999), o Praxis (PAULA FILHO, 2001) e o
2.2.3. Diagrama de Classes
O diagrama de classes é um recurso da UML, utilizado para a tarefa de modelagem conceitual, que consiste em uma representação gráfica de um conjunto de elementos de um domínio e que descreve a visão estática de um sistema, em termos de classes e relacionamentos entre estas, sendo sempre válida em qualquer ponto do ciclo de vida do mesmo.
Um diagrama de classes mostra as classes, bem como os relacionamentos existentes entre elas, modeladas a partir do domínio do problema, fornecendo o modelo lógico de dados para o sistema. Este modelo é equivalente ao modelo entidade-relacionamento da notação estruturada (PAULA FILHO, 2001).
Durante a modelagem conceitual, na construção do diagrama de classes, o primeiro passo consiste em identificar as classes que representam adequadamente os conceitos expressos nos requisitos anteriormente levantados. Neste passo, os atributos que descrevem tais classes, representando suas características, também devem ser identificados. Uma vez que as classes devem ser provenientes do domínio do problema, é conveniente que este passo seja realizado com o apoio de especialistas no mesmo.
Para identificar classes chaves do modelo conceitual deve-se analisar a especificação de requisitos do software, realizada anteriormente, atentando-se para identificar coisas tangíveis e papéis que estas desempenham (PAULA FILHO, 2001). Segundo ERIKSSON e PENKER (1998), devem-se primeiramente questionar se existe informação sobre o que deveria ser armazenado ou analisado no sistema e, caso exista qualquer informação que deva ser armazenada, transformada, analisada ou manipulada de algum modo, então ela é uma possível candidata a uma classe.
Para identificação dos atributos, que são propriedades que descrevem as classes, devem-se listar as responsabilidades de uma classe que são relevantes para o domínio em questão (PAULA FILHO, 2001).
Na UML, a classe é representada por um retângulo divididos em três compartimentos, que contêm, respectivamente, o nome da classe, os seus atributos e as operações. Porém, para maior clareza nos diagramas, pode-se
suprimir dos retângulos que representam, nas classes, cada um dos compartimentos de atributos e operações, deixando de mostrá-los. Isto será feito neste trabalho, uma vez que o foco aqui se concentra na natureza dos conceitos representados pelas classes, não sendo relevantes para este estudo seus atributos e operações. A Figura 2.1 mostra um exemplo das possíveis representações de uma classe em UML.
Cliente Código Nome RG CPF Endereço Telefone Data de Nascimento Incluir Cliente() Excluir Cliente() Listar Clientes() Cliente Cliente Código Nome RG CPF Endereço Telefone Data de Nascimento (a) (b) (c)
Figura 2.1 – (a) Representação da classe Cliente em UML, exibindo os seus atributos e operações. (b) Representação da classe Cliente em UML, exibindo apenas os seus atributos. (c) Representação da classe Cliente em UML, não exibindo seus atributos e nem suas operações.
No próximo passo, os relacionamentos entre as classes identificadas devem ser definidos, revelando a maneira que cada classe do domínio se coloca em relação às outras.
2.2.3.1. Tipos de Relacionamentos 2.2.3.1.1. Associação
Os relacionamentos de associação consistem em uma conexão entre duas ou mais classes, que denotam ligação entre objetos das mesmas.
Em UML, uma associação é definida como um relacionamento que descreve um conjunto de ligações, onde cada ligação é definida como uma conexão semântica entre objetos, que são instâncias das classes participantes da associação (ERIKSSON e PENKER, 1998).
A associação no diagrama de classes é representada por uma linha que conecta duas ou mais classe e possui um nome, que aparece, opcionalmente,
perto da linha que a representa, como mostrado na Figura 2.2. Tal nome deve ser proveniente do domínio do problema, assim como os nomes das classes.
Professor Leciona Disciplina
Figura 2.2 – Associação Leciona entre as classes Professor e Disciplina.
Normalmente, na definição de um relacionamento de associação, também devem ser definidos a multiplicidade e os papéis das classes participantes do relacionamento. A multiplicidade de participantes indica quantos objetos de uma classe podem estar relacionados com cada objeto da outra classe, representando uma faixa (zero-um (0..1), zero-muitos (0..n), um-muitos (1..n), etc.), que exibe a quantidade mínima e máxima de objetos de cada classe que estão relacionados. A multiplicidade é mostrada perto do final da associação, para a classe onde é aplicável. Os papéis são denominações que exprimem em que qualidade um objeto de uma das classes do relacionamento se relaciona com um objeto da outra classe. O nome do papel é uma string localizada perto do final da associação, próximo à classe a qual ele se aplica. No caso de papéis cujo significado seja óbvio, devido aos nomes das classes, não é necessário denominá-los. O mesmo ocorre com a denominação de relacionamentos.
A Figura 2.3 mostra uma associação que indica que um objeto da classe
Empresa participa do relacionamento Fornece, no papel de Fornecedor, com
zero ou mais objetos da classe Produto e que cada objeto desta classe se relaciona com um ou mais objetos da classe Empresa. A multiplicidade no relacionamento indica que cada empresa pode fornecer zero ou mais produtos e que cada produto deve ser fornecido por, no mínimo uma, ou mais empresas.
Empresa 1..n Fornece 0..n Produto
+Fornecedor
0..n 1..n
Figura 2.3 – Associação Fornece com suas multiplicidades e o papel da classe
2.2.3.1.2. Agregação
Um relacionamento de agregação é um tipo especial de associação que indica que o relacionamento entre as classes é do tipo “todo-parte”, refletindo construção física ou posse lógica. Uma agregação normalmente descreve diferentes níveis de abstração e utiliza as palavras-chave “consiste de”, “contém”, “é parte de” na descrição do relacionamento entre as classes envolvidas (ERIKSSON e PENKER, 1998).
No diagrama de classes da UML, um relacionamento de agregação é representado por uma linha conectando as classes relacionadas, como em qualquer associação, porém adicionada de um losango ligado ao final da linha, do lado da classe que representa o “todo” no relacionamento.
Existem dois tipos de relacionamentos de agregação, dependendo do compartilhamento ou não, pela classe que representa o “todo”, de alguma de suas partes com outro “todo”.
2.2.3.1.2.1. Agregação Compartilhada
Uma agregação compartilhada é aquela em que as partes podem estar ligadas a mais de um “todo”. Isto é demonstrado pela multiplicidade maior que um (1) do lado “todo”. A Figura 2.4 mostra um exemplo de agregação compartilhada, onde um funcionário, que representa a classe “parte”, pode ser membro de várias equipes.
Funcionário nn É membro nn Equipe
Figura 2.4 – Exemplo de agregação compartilhada, envolvendo a classe “parte”
Funcionário e a classe “todo” Equipe.
2.2.3.1.2.2. Composição
O relacionamento de composição consiste em um tipo mais forte de relacionamento “todo-parte”. Neste caso, um objeto da classe “parte” não possui existência própria, ou seja, se o “todo” for destruído, suas partes serão destruídas juntamente. A multiplicidade no lado “todo” do relacionamento deve ser um (1), mas a multiplicidade no lado “parte” pode ser qualquer intervalo.
Uma vez que o relacionamento de composição constitui-se num tipo de agregação, no diagrama de classes da UML uma composição é representada da mesma forma que uma agregação comum, porém o losango ligado ao lado “todo” do relacionamento é sólido.
A Figura 2.5 mostra um exemplo de composição entre a classe “todo”
Caixa de Mensagem e as classes “partes” Botão Ok, Botão Cancelar e
Informação. Note que, para que objetos das classes Informação, Botão Ok e
Botão Cancelar existirem, eles devem fazer parte de um objeto da classe Caixa
de Mensagem. Informação Botão Cancelar Botão OK Caixa de Mensagem 1 0..1 1 1 0..1 1 1 0..1 0..1 1 0..1 0..1
Figura 2.5– Exemplo de composição, envolvendo as classes “partes” Informação,
Botão Cancelar e Botão OK e a classe “todo” Caixa de Mensagem.
2.2.3.1.3. Generalização
Uma generalização é definida em UML, segundo ERIKSSON e PENKER (1998), como sendo um relacionamento taxonômico (classificatório) entre um elemento mais geral e um elemento mais específico. O elemento mais específico é completamente consistente com o elemento mais geral e contém apenas informação adicional, herdando deste último todas as suas características. Porém, os atributos e operações herdadas do elemento mais geral podem ser alterados, sem nenhum problema, dentro do elemento mais específico. Uma instância do elemento mais específico pode ser usada sempre que o elemento mais geral for permitido.
Generalização está intimamente relacionada aos conceitos de superclasse, subclasse, especialização e herança. As noções de superclasse e subclasse aparecem quando uma classe pode ser classificada em subgrupos que sejam significativos para o domínio do problema, de modo que casos
especiais ou extensões possam ser facilmente tratados como elementos separados. Nas subclasses, devem ser localizadas operações ou atributos que só se aplicam a um subconjunto das instâncias de uma classe. A identificação de superclasses é feita quando são localizados atributos ou operações comuns a um grupo de classes. Por exemplo, a classe Veículo pode ser divida nos subgrupos Carro, Barco e Avião. Assim, cada um destes subgrupos, que possuem características distintas, é uma subclasse da classe Veículo, que é chamada então de superclasse.
As subclasses herdam todas as características, como atributos, operações e relacionamentos, de sua superclasse, uma vez que um objeto que representa uma instância da subclasse é também instância de sua superclasse.
Especialização é o nome dado ao processo de definir um conjunto de subclasses específicas, tomando por base algumas características distintivas de uma classe geral denominada superclasse (ELMASTRI e NAVATHE, 2000). Por exemplo, a classe Empregado pode ser especializada nas subclasses
Empregado Horista e Empregado Assalariado, uma vez que existem
empregados que recebem um salário, ao final do mês trabalhado, e outros que recebem por hora trabalhada. Estes mesmos autores definem Generalização como sendo o processo inverso da Especialização, em que uma classe mais geral (superclasse) é obtida tomando-se por base as características em comum de classes específicas (subclasses) já existentes. Porém, no presente trabalho, o termo generalização será utilizado, como definido em UML, para especificar de maneira geral um relacionamento hierárquico entre superclasse e subclasses, sendo algumas vezes chamado de relacionamento “é um” entre o elemento especializado e o elemento geral.
O relacionamento de generalização, no diagrama de classes UML, é mostrado como uma linha partindo da subclasse para a superclasse, com um triângulo no final da linha do lado da superclasse. A Figura 2.6 mostra um exemplo de relacionamento de Generalização, unindo a superclasse Veículo às suas subclasses Carro, Barco e Avião.
Veículo
Carro Barco Avião
Figura 2.6 – Exemplo de relacionamento de Generalização, com as subclasses
Carro, Barco e Avião herdando as características da superclasse Veículo.
Uma classe pode estar presente em uma hierarquia de classes, representando uma superclasse e uma subclasse ao mesmo tempo, como mostrado na Figura 2.7. Dessa forma, uma classe herda características de outra classe (neste caso, constituindo-se uma subclasse desta última) e ao mesmo tempo pode ter suas características herdadas por outra classe (neste caso, sendo uma superclasse desta).
Veículo
Carro Barco Avião
Carro de Passeio
Utilitário
Figura 2.7– Exemplo de relacionamento de Generalização, com uma hierarquia de classes. A classe Carro é uma subclasse de Veículo e ao mesmo tempo superclasse de Carro de Passeio e Utilitário.
O relacionamento de generalização também pode conduzir ao conceito de classes abstratas. Uma classe abstrata é uma classe que não possui objetos como instâncias, sendo utilizada como uma superclasse, em uma hierarquia de classes, apenas para descrever atributos e comportamentos comuns que são herdados por outras classes. Na Figura 2.8, a superclasse
Pagamento é uma classe abstrata, pois qualquer objeto que seja um
pagamento é instância de alguma de suas subclasses Pagamento com
Dinheiro, Pagamento com Cartão de Crédito, Pagamento com Cartão de
apenas para capturar as características em comum entre todos os tipos de pagamentos, que são herdadas por suas subclasses.
Pagamento Pagamento com Dinheiro Pagamento com Cartão de Crédito Pagamento com Cartão de Débito Pagamento com Cheque
Figura 2.8 – Exemplo de Generalização com a superclasse abstrata Pagamento.
2.2.3.1.3.1. Generalização Restrita
Podem existir restrições semânticas sobre relacionamentos de generalização envolvendo mais de uma subclasse, especificando informação adicional sobre como a generalização poderia ser utilizada e estendida no futuro. Tais restrições são exibidas entre chaves próximas ao triângulo ligado à superclasse, caso existam várias linhas conectadas ao mesmo triângulo, ou, se as linhas conectando as subclasses à superclasse não compartilham um triângulo em comum, uma linha pontilhada deve cruzar todas as tais linhas e as restrições deverão ser exibidas entre chaves, próximas à linha pontilhada.
Uma generalização é considerada de sobreposição quando é possível especificar classes adicionais, a partir de duas ou mais subclasses, em uma hierarquia de classes. Generalização Disjunta é o oposto da generalização de sobreposição, uma vez que não permite que as subclasses se especializem em uma classe comum. A Figura 2.9 mostra um exemplo de uma generalização de sobreposição, com a classe Cliente-Funcionário herdando características das classes Cliente e Funcionário.
Pessoa
Cliente Funcionário
Cliente Funcionário
Figura 2.9 – Exemplo de uma Generalização de Sobreposição.
Uma generalização é completa se todas as subclasses possíveis foram especificadas, não permitindo que nenhuma subclasse adicional possa ser especificada futuramente. Já uma generalização incompleta, que é o padrão de generalização, significa que subclasses poderão ser adicionadas futuramente. A Figura 2.10 mostra um exemplo de generalização completa, pois todas as subclasses de pessoa, no que se refere ao sexo, foram especificadas, uma vez que uma pessoa somente pode ser homem ou mulher.
Pessoa
Homem
Mulher
Figura 2.10 – Exemplo de uma Generalização Completa.
{completa} {sobreposição}
3. O USO DE ONTOLOGIAS PARA MODELAGEM CONCEITUAL
DE SISTEMAS
Conforme exposto anteriormente, modelagem conceitual consiste na identificação, análise e descrição dos elementos e restrições de um domínio do mundo real, normalmente utilizando uma linguagem de modelagem, a fim de que tais elementos sejam incorporados em um sistema de informação. Já modelagem ontológica pode ser definida como a criação de uma ontologia específica de domínio, através da captura das entidades relevantes do domínio e incorporação das mesmas em um conjunto de categorias que revelam sua natureza, por meio de uma linguagem de especificação de ontologia.
Como é possível perceber, existe uma forte semelhança entre esses dois tipos de modelagem, uma vez que ambas objetivam capturar e modelar elementos do mundo real. Porém, enquanto na modelagem conceitual busca-se estabelecer as relações entre os conceitos abstraídos de um domínio, na modelagem ontológica o objetivo é identificar os objetos do domínio e entender sua natureza, por meio da descrição de suas propriedades. Segundo POLI (2001), a primeira modelagem possui um caráter epistemológico, em oposição ao caráter ontológico da segunda. Dessa forma, pode-se deduzir que as duas modelagens são possivelmente complementares, ou seja, a modelagem ontológica pode constituir-se numa base para modelagem conceitual, no sentido de prover ao projetista, de forma clara e sem ambigüidades, o conhecimento necessário sobre o domínio a ser modelado.
3.1. Ontologia
A palavra Ontologia, definida originalmente na Filosofia como a ciência que estuda “os tipos de coisas que existem no mundo”, tem sido utilizada com diferentes sentidos na área de Inteligência Artificial e Engenharia do Conhecimento, o que tem provocado uma certa descaracterização do termo.
MOREIRA (2003) faz uma discussão detalhada sobre os significados do termo Ontologia na Filosofia e na Ciência da Computação. No sentido filosófico, Ontologia pode ser definida, em linhas gerais, como a teoria do ser, se ocupando de responder as perguntas “quem existe?” e “que é consistir?”. O
ramo da ontologia que se ocupa em responder a primeira pergunta é a Metafísica e a que responde a segunda questão é chamada de teoria do objeto, teoria da objetividade ou teoria da consistência dos objetos em geral (MORENTE, 1964). Ontologia, dentro da filosofia de Aristóteles, teve também influência na Ciência da Computação, e está associada a dez categorias básicas que ele utiliza para classificar tudo o que existe no mundo e que revelam a sua visão ontológica deste.
Ainda segundo MOREIRA (2003), o termo Ontologia começou a ser utilizado na Ciência da Computação, mais precisamente na sub-área de Inteligência Artificial (IA), em projetos para organização de grandes bases de conhecimento, no início dos anos 90, quando houve um impulso para criação de bases de conhecimento compartilháveis e reutilizáveis, a fim de reduzir custos.
JASPER e USCHOLD (1999), citados por MOREIRA (2003), identificaram quatro categorias principais de aplicações para Ontologias na Ciência da Computação:
Autoria Neutra: informação é criada em um único idioma, sendo convertida em formatos diferentes para uso em diferentes sistemas.
Ontologia como especificação: ontologia com informações específicas sobre um domínio é criada e utilizada como base para especificação e desenvolvimento de software.
Acesso comum à Informação: ontologia torna a informação, expressa em vocabulário pouco conhecido, ou em formato inacessível, inteligível, provendo um entendimento compartilhado dos termos.
Busca baseada em Ontologia: uma ontologia é usada para procurar recursos desejados em um repositório de informações (como documentos ou páginas Web).
Apesar do termo Ontologia estar presente em diversas áreas da Ciência da Computação, ainda não existe um consenso sobre o seu significado.
GUARINO e GIARETTA (1995), com o objetivo de fornecer um esclarecimento a respeito do significado do termo “Ontologia”, apresentam algumas possíveis interpretações para o mesmo, sendo visto tanto como entidade semântica conceitual, quanto como um objeto sintático específico. No entanto, os autores concentram-se numa análise minuciosa da definição de Ontologia fornecida por GRUBER (1993), como sendo “uma especificação explícita de uma conceitualização”. Esta definição tem sido a mais utilizada pela comunidade da área de Inteligência Artificial e pode ser classificada como uma interpretação sintática para Ontologia (GUARINO e GIARETTA, 1995), uma vez que trata ontologia como um produto concreto sintático e manipulável.
MOREIRA (2003) mostra um exemplo para ilustrar as noções de conceitualização e especificação. Uma conceitualização da visão do mundo formada pelo domínio acadêmico poderia conter os conceitos aluno, professor,
disciplina, nota, curso, etc. Uma especificação explícita desta conceitualização
poderia ser constituída de sentenças descritas em lógica de primeira ordem, como descritas na Tabela 3.1.
Sentença em Lógica Linguagem Natural
∀x disciplina(x) ⇒ ∃y(professor(y) ∧ ministra(x,y)) Para toda disciplina existe
um professor que a ministra.
∀x disciplina(x) ⇒ ∃y(curso(y) ∧ parte-de(x,y)) Toda disciplina é parte de um
curso.
∀x aluno(x) ⇒ ∃y(curso(y) ∧ cursa(x,y)) Todo aluno cursa um curso.
∀x aluno(x) ⇒ Corpo-acadêmico(x) Todo aluno é parte de um
corpo acadêmico.
∀x professor(x) ⇒ Corpo-acadêmico(x) Todo professor é parte de
um corpo acadêmico.
∀x aluno(x) ∧ Inteligente(x) Existem alunos que são
inteligentes.
Tabela 3.1 – Especificação explícita de uma conceitualização. Fonte: MOREIRA (2003)
De forma semelhante, GUARINO e GIARETTA (1995) propõem a utilização do termo “conceitualização” para denotar uma estrutura semântica que reflete um sistema conceitual, dentro de um aspecto intensional, ou seja, uma relação descrevendo todos os possíveis estados particulares de um
mundo; e o termo “teoria ontológica” para denotar a teoria lógica, como vista na Tabela 3.1, utilizada para expressar conhecimento ontológico, no nível sintático. Assim, o termo “ontologia”, compatível com a definição de GRUBER (1993), corresponde a uma teoria ontológica, desde que esteja claro que o significado da palavra “explícito”, em tal definição, seja um objeto concreto, em nível simbólico.
GUARINO e GIARETTA (1995) afirmam que um conjunto de restrições formais, expresso por meio da teoria ontológica e utilizado a fim de se limitar as extensões admissíveis de uma conceitualização, pode caracterizá-la apenas parcialmente, uma vez que tais restrições podem representar diferentes modelos do mundo (conceitualizações). O conjunto de tais modelos, representados pela teoria ontológica, é que os autores definem como
compromisso ontológico.
A fim de proporcionar um melhor esclarecimento do que vem a ser
compromisso ontológico, na definição de GUARINO e GIARETTA (1995), será
apresentado um exemplo, semelhante ao mostrado no referido artigo. Seja T1, uma teoria lógica, conforme descrita abaixo:
∀x cachorro(x) ⇒ animal(x)
∀x gato (x) ⇒ animal(x)
cachorro(Rex) gato(Tob)
A teoria ontológica T2, subjacente a T1, é obtida isolando-se o conteúdo ontológico de T1, tomando somente as sentenças que traduzem conhecimento intensional, ou seja, que sejam verdadeiras em todos os estados do mundo, e que podem ser vistas como uma tradução de parte do significado de cachorro,
gato e animal:
∀x cachorro(x) ⇒ animal(x)
∀x gato (x) ⇒ animal(x)
Uma teoria ontológica, como T2, caracteriza apenas superficialmente o conteúdo ontológico de T1. A fim de proporcionar uma melhor caracterização do seu conteúdo, deve-se observar a conceitualização pretendida, subjacente a T1 e T2, que modela os aspectos ontologicamente relevantes da linguagem
utilizada pela teoria inicial T1. Tal conceitualização pode ser (parcialmente) caracterizada, utilizando-se operadores modais, como o operador ٱ, cujo significado é “em todos os possíveis mundos”, conforme mostrado em T3, abaixo: ٱ(∀x cachorro(x) ⇒ animal(x)) ٱ(∀x gato (x) ⇒ animal(x)) ٱ(∀x cachorro(x) ⇒ ٱ cachorro(x)) ٱ(∀x gato(x) ⇒ ٱ gato(x)) ٱ(∀x animal(x) ⇒ٱanimal(x)) ¬ٱ(∀x pêlo(x) ⇒ ٱpêlo(x))
Esta teoria expressa algumas restrições gerais sobre o significado dos predicados: cachorro, gato, animal e pêlo. T3 é dita ser, então, a especificação do compromisso ontológico de T1.
Baseados no que foi acima exposto, GUARINO e GIARETTA (1995) colocam que o termo “ontologia”, segundo a definição de GRUBER (1993), pode ser interpretado como “uma teoria lógica que define explicitamente e parcialmente uma conceitualização”.
VALENTE (1995), citado por MOREIRA (2003), define comprometimento
ontológico como sendo as escolhas que levaram a selecionar um determinado
conjunto de conceitos dentro de um determinado domínio, em detrimento de outro. Com base nesta definição de comprometimento ontológico, e de forma semelhante à interpretação de ontologia proposta por GUARINO e GIARETTA (1995), MOREIRA (2003) afirma que o registro explícito e formal dos
comprometimentos ontológicos é o que tem sido normalmente denominado de
ontologia, na área de Inteligência Artificial.
MOREIRA (2003) salienta que, conforme discutido em GUARINO (1995) e POLI (2001), deve-se atentar para o tipo de conhecimento embutido em uma ontologia. Muitas vezes, o conhecimento no nível ontológico é confundido com conhecimentos dos níveis lógico e epistemológico. No nível lógico, o conhecimento é codificado por meio de primitivas básicas, como predicados e funções, como mostra a primeira coluna da Tabela 3.1. No nível epistemológico, o conhecimento é estruturado, relacionando-se seus conceitos
através de primitivas de estruturação, como mostrado na segunda coluna da Tabela 3.1. Já no nível ontológico, os compromissos ontológicos associados aos conceitos relativos ao conhecimento são especificados explicitamente (GUARINO, 1995), sendo fornecida uma descrição da natureza destes conceitos. Um exemplo de conhecimento do nível ontológico, ainda no domínio acadêmico, seria “Todo aluno é um objeto material” e “Inteligente é uma
qualidade” (MOREIRA, 2003).
3.2. Ontologias Formais
Ontologia Formal pode ser definida como o registro dos compromissos ontológicos feitos através de uma linguagem formal, com uma semântica bem definida (MOREIRA, 2003).
COCHIARELLA (1991) definiu Ontologia Formal como sendo “o desenvolvimento sistemático, axiomático e formal de todas as formas e modos de ser”.
GUARINO (1995) afirma que, de acordo com a definição de COCCHIARELLA (1991), Ontologia Formal está relacionada com a descrição rigorosa das características estruturais dos objetos e que, na prática, pode ser vista como a teoria das distinções entre as entidades do mundo (objetos físicos, eventos, etc.) e as categorias nível-meta utilizadas para modelar o mundo (conceito, propriedade, qualidade, estado, etc.).
Ontologias formais podem abranger desde termos gerais que formam o fundamento para a representação de conhecimento em todos os domínios, denominadas “Ontologias de Nível Topo”, até termos que são restritos a domínios de conhecimentos específicos, denominados “Ontologias de Domínio”.
3.2.1. Ontologias de Nível Topo
Ontologias de nível topo são utilizadas para classificar os elementos de uma ontologia de domínio, aperfeiçoando, assim, o entendimento de suas estruturas e seus relacionamentos. Seu objetivo principal é fornecer um “framework” para organização dos objetos de qualquer domínio.
GUARINO e WELTY (2000a, 2000b), mostram como uma ontologia de nível topo pode ajudar na utilização correta de relações hierárquicas entre elementos de um domínio, o que depende de uma compreensão correta da natureza das propriedades do domínio correspondentes aos nós taxonômicos da ontologia. A fim de facilitar tal compreensão, os autores apresentam algumas meta-propriedades derivadas de noções filosóficas, discutidas posteriormente no capítulo 4, que, combinadas de maneira sistemática, formam uma ontologia de nível topo.
DEGEN et al. (2001) apresentam a ontologia de nível topo subjacente à linguagem de modelagem GOL (General Ontology Language). A linguagem
GOL pode ser vista como uma extensão de linguagens de modelagem
ontológica padrão, tais como KIF (GENESERETH e FIKES, 1992) e similares, que são limitadas aos princípios de construção da teoria de conjuntos. GOL mantém teoria de conjuntos como parte de sua ontologia nível topo, aceitando relação de elementos de teoria de conjuntos, além de introduzir várias outras relações ontologicamente básicas e tipos.
O modelo ontológico apresentado por BUNGE (1977, 1979), com o objetivo de fornecer uma ontologia exata e científica, também consiste em uma ontologia de nível topo, uma vez que trabalha com elementos abstratos de alto nível que objetivam representar todos os fenômenos do mundo real. Tal modelo é baseado em tradições ontológicas provenientes da Filosofia e em pesquisas atuais, sendo elaborado por meio de conceitos matemáticos. A categoria mais geral neste modelo são “coisas” (things), que se referem a coisas concretas ou entidades reais do mundo. “Coisas” possuem
propriedades. Uma propriedade pode ser “intrínseca”, que significa que se
aplica a apenas uma “coisa”, ou “mútua”, significando que depende de duas ou mais “coisas”. Um exemplo seria o “peso” de uma pessoa, que consiste em uma propriedade intrínseca, uma vez que depende apenas da existência da pessoa. Já a propriedade “ser um estudante” seria uma propriedade mútua, uma vez que depende da existência de uma pessoa e também de uma escola. Uma classe é definida por um conjunto de “coisas” possuindo uma propriedade em comum e um tipo é definido por um conjunto de propriedades. “Coisas” similares podem ser representadas pelo mesmo modelo, sendo que um modelo
específico de uma “coisa” consiste num esquema funcional. “Coisas” podem interagir e podem também ser associadas, para formar uma outra “coisa”.
RUSSELL e NORVIG (1995) também apresentam uma ontologia de nível topo cujas categorias mais gerais são Objetos Abstratos e Eventos. Objetos abstratos são divididos em Conjuntos, Números, e Objetos
Representacionais. Eventos são classificados em Intervalos, Lugares, Objetos
Físicos e Processos. A classe de Categorias é uma subclasse da classe de
Conjuntos. Esta ontologia inclui a relação de instanciação, identificada como “membership”, e a relação “parte-de”. Um Evento consiste num acontecimento com extensão temporal e espacial. Um Intervalo é um evento que inclui como sub-eventos todos os eventos ocorridos em um dado período de tempo.
3.2.2. Ontologias de Domínio
Ontologias de Domínio modelam informações relativas a domínios de conhecimento específicos, através da incorporação de termos pertencentes a estes em uma Ontologia de Nível Topo.
Nesse sentido, ontologias de domínio podem ser vistas como uma descrição detalhada da natureza de elementos pertencentes a domínios específicos, podendo ser utilizadas como fonte de conhecimento do domínio e, conseqüentemente, ferramentas de suporte, para a tarefa de modelagem conceitual de sistemas.
3.3. Fundamentos Ontológicos de Modelagem Conceitual
Apresentaremos aqui uma breve descrição de alguns trabalhos que relacionam ontologias e modelagem conceitual, com diferentes abordagens.
3.3.1. Ontologias de Nível Topo Como Ferramentas de Análise de Modelos Conceituais
GUIZZARDI et al. (2002b) utilizam a linguagem GOL, e sua ontologia de nível topo subjacente, para avaliar a corretude ontológica de construtores utilizados em modelos conceituais expressos na forma de diagrama de classes em UML e para desenvolver guias sobre como tais construtores da UML
deveriam ser utilizados. Associações entre conceitos de GOL e conceitos de
UML são realizadas e algumas propostas de se utilizar mecanismos de
extensão existentes na UML são feitas, no sentido de se obter um tratamento mais satisfatório de relacionamento de agregação.
Baseado em noções ontológicas, GUIZZARDI et al. (2002b) definem partes inseparáveis e partes essenciais, em uma agregação, como segue:
• O conceito de partes inseparáveis refere-se à impossibilidade de um objeto existir não sendo parte de um todo particular. Esta definição leva em consideração o tempo de vida de um todo e suas partes. Dessa forma, sejam w um todo e p uma de suas partes, então p é uma parte inseparável de w se TempoDeVida(p) ≤ TempoDeVida(w)
e a destruição de w implica na destruição de p.
• O conceito de partes essenciais refere-se à impossibilidade de um objeto existir não possuindo um objeto particular como parte.
Como exemplo destes dois conceitos, considere a relação entre uma pessoa e seu cérebro. Este último constitui-se em parte essencial da primeira, pois é impossível uma pessoa existir sem ter um cérebro como parte de seu corpo, sendo ele necessariamente o mesmo durante toda a sua existência. Cérebro também é uma parte inseparável de pessoa, pois não é possível um cérebro existir sem fazer parte do corpo de uma pessoa. Já na relação entre pessoa e coração, este último consiste em uma parte não essencial e separável da primeira, pois uma pessoa pode continuar vivendo, enquanto adquire outro coração através de um transplante; e um coração também pode continuar existindo, mesmo não estando dentro do corpo de uma pessoa, como por exemplo no espaço de tempo entre a retirada de um doador e sua utilização em um transplante.
Dessa forma, a fim de representar estas duas distinções ontológicas, os autores propõem utilizar uma extensão da versão 1.4 de UML, para adicionar os seguintes rótulos “booleanos” ao lado parte de uma agregação: essencial e
Pessoa Cérebro 1 1 1 1 {essencial=true, inseparável=true}
Figura 3.1 – Exemplo de composição com parte inseparável e essencial. Fonte: GUIZZARDI et al. (2002b).
Um outro conceito tratado por GUIZZARDI et al. (2002b) é o de transitividade, que é bastante delicado dentro do domínio de filosofia e matemática, e deve ser minuciosamente analisado em modelagem conceitual. Em modelagem orientada a objetos, mais precisamente em UML, transitividade tem sido proposta como uma característica básica de agregação. Por exemplo, pode-se dizer que, se a Mão é parte do Braço e o Braço é parte do Corpo Humano, então a Mão é parte do Corpo Humano também. Todavia, existem vários autores que afirmam que transitividade não deve sempre ser aplicada. Tome-se, como exemplo, se um Cérebro é parte de uma Pessoa e esta Pessoa é parte de um Grupo de Pesquisa, não é conveniente dizer que o Cérebro da pessoa seja parte do Grupo de Pesquisa.
A fim de superar tal problema com transitividade, GUIZZARDI et al. (2002b) propõem estender a UML, através da adição de um construtor de agregação contextual, que envolve o conceito de relação todo-parte material (contextual) de GOL. Neste tipo de relação, a transitividade é válida dentro de um certo contexto, em contraste à relação todo-parte formal, que é irrestritamente transitiva. Para definir o contexto da relação todo-parte contextual, foi proposto utilizar o construtor UML de um pacote, conforme mostrado na Figura 3.2.
Figura 3.2 - O mesmo indivíduo pesquisador participando de diferentes relações
todo-parte contextual. Fonte: GUIZZARDI et al. (2002b).
WAND et al. (1999) apresentam uma abordagem bastante próxima à apresentada por GUIZZARDI et al. (2002b), em que a ontologia de nível topo desenvolvida por BUNGE (1977, 1979) é utilizada para analisar o significado de construtores de modelagem conceitual. Com base nesta análise, e em um mapeamento realizado entre construtores ontológicos e construtores de modelagem conceitual, com o objetivo de atribuir uma semântica precisa a estes e resolver as dificuldades inerentes à modelagem de relacionamentos, WAND et al. (1999) propõem um conjunto de regras que servem como fundamento para prática de modelagem conceitual.
Tais regras objetivam fornecer um significado mais preciso para alguns construtores importantes de modelagem conceitual, buscando, em particular, reduzir a ambigüidade semântica. Elas fornecem também suporte teórico para práticas de modelagem existentes, impondo às mesmas um conjunto de restrições e proibições como, por exemplo:
• Proíbe utilizar entidades ou objetos para conectar outras entidades ou objetos, bem como modelar atributos como entidades ou objetos.
• Proíbe a utilização de relacionamentos para modelar entidades ou objetos compostos.
• Se uma entidade (ou objeto) adquire uma propriedade que é importante para os propósitos de modelagem, tal entidade (ou objeto) deve ser modelada por um novo esquema funcional, que representa uma outra entidade (ou objeto).
• Um tipo/classe agregado deve ter propriedades adicionais a aquelas de seus componentes.
• Atributos e relacionamentos não devem ser opcionais, mas obrigatórios. WAND et al. (1999) utilizam os fundamentos ontológicos baseados no modelo desenvolvido por BUNGE (1977, 1979) e as regras para modelagem conceitual, anteriormente mencionadas, a fim de derivar regras adicionais para modelar relacionamentos em modelagem Entidade-Relacionamento (ER). Tais regras, mostradas abaixo, tratam de relacionamentos com atributos, relacionamentos binários e de ordem superior, relacionamentos obrigatórios e opcionais e entidades (ou objetos) compostas, sendo que algumas delas deverão ser utilizadas no presente trabalho, devido sua importância para o esclarecimento semântico de modelos conceituais.
• Relacionamentos com Atributos:
1. Não se deve ter atributo em relacionamentos, pois, de acordo com o modelo ontológico seguido, propriedades não podem ter propriedades; e tanto relacionamento quanto atributo consistem em propriedades, sendo o primeiro uma propriedade mútua e o segundo uma propriedade intrínseca. WAND et al. sugerem, neste caso, que um atributo de relacionamento seja então modelado como um relacionamento.
• Relacionamentos Binários e de Ordem Superior:
2. O modelo ontológico utilizado (BUNGE, 1977; 1979) proíbe a representação de tipos relacionamento através de uma linha sem nenhum símbolo intermediário entre os tipos entidade relacionados.
3. Todos os atributos mútuos (que envolvem duas ou mais entidades) devem ser representados como relacionamentos no modelo ER.
• Relacionamentos Obrigatórios e Opcionais
4. Relacionamentos opcionais devem ser evitados.
5. A aquisição e a perda de uma propriedade mútua (relacionamento) deveria ser modelada como uma mudança em tipo/classe.
6. A habilidade de instâncias de uma classe adquirirem interação (propriedade mútua) sem perder suas propriedade poderia ser modelada como sub-classificação, ou seja, em modelagem ER, deve-se utilizar o construtor “É-UM” ao invés de relacionamentos opcionais. Utilização do construtor “É-UM” permite que todos os tipos entidades sejam modelados apenas com atributos (intrínsecos ou mútuos) obrigatórios.
É válido observar que a regra 5 acima refere-se a uma instância de uma entidade do domínio, enquanto que a regra 6 refere-se à estrutura de classificação das entidades do domínio.
Para ilustrar algumas implicações de tais regras WAND et al. (1999) mostram o exemplo de estudantes universitários que podem tomar livros emprestados em uma biblioteca. Quando um estudante pega um livro emprestado, o livro torna-se indisponível na biblioteca. Além disso, o estudante torna-se responsável por devolver o livro. Os estados do estudante e do livro mudaram. Assim, estudantes e livros podem interagir, o que é freqüentemente representado através de um relacionamento opcional, como mostrado na Figura 3.3. Quando um estudante de fato toma um livro emprestado, o estudante e o livro adquirem uma propriedade mútua. De acordo com as regras anteriores, o estudante e o livro deveriam ser agora descritos por novos esquemas funcionais, representados como novos tipos de entidades. O estudante torna-se um devedor, e o livro torna-se um livro-emprestado. Na Figura 3.4, observe que as regras proíbem a utilização de cardinalidade de zero para o relacionamento “Toma Emprestado”.
Figura 3.3 – Utilização de um relacionamento opcional.
Figura 3.4 – Estudante e Livro adquirem uma propriedade mútua – Toma
emprestado. Fonte: WAND et al. (1999).
WAND et al. (1999) apresentam alguns problemas provenientes da utilização de relacionamentos opcionais e as vantagens se utilizar subtipos no lugar de relacionamentos opcionais. Dentre os problemas com tais tipos de relacionamentos, os referidos autores argumentam que relacionamentos opcionais não modelam uma situação adequadamente quando a “aquisição” de um relacionamento assinala alterações fundamentais nas propriedades de uma entidade do domínio. Também é afirmado que o uso de relacionamentos opcionais pode levar a ambigüidades semânticas e inconsistências, pois um único esquema funcional é utilizado para descrever duas classes de “coisas”, ou seja, aquelas que participam e aquelas que não participam do relacionamento. Como exemplo, WAND et al. apresentam a situação em que um artigo é submetido a um jornal. Este artigo pode ser aceito ou não. Se o artigo é aceito, ele se torna um artigo publicado, acarretando alterações importantes em suas propriedades. A reclassificação de tal artigo, como um subtipo “artigo publicado” da classe genérica “artigo” modela melhor, segundo os autores, tais alterações do que a utilização de um relacionamento opcional entre “artigo” e “jornal”.
Livro Toma emprestado Estudante 0..n 0..1 Livro Emprestado Toma emprestado Devedor n 1 Estudante Livro É-UM É-UM
• Entidades (ou Objetos) Compostos:
7. Tanto a classe de “coisas” compostas (agregado), quanto seus componentes, deveriam ser representados como tipos entidade. 8. Cada componente deveria estar ligado à entidade composta
através de um relacionamento “parte-de”.
9. As propriedade emergentes de um composto deveriam ser modeladas como atributos e tipos de relacionamentos.
Tais regras, relacionadas a entidades compostas, possuem várias implicações, segundo WAND et al. (1999). Dentre elas pode-se perceber que, como um composto é uma “coisa”, segundo o modelo ontológico de BUNGE (1977, 1979), ele deve possuir suas próprias propriedades. Assim, é requerido que um composto deva possuir no mínimo uma propriedade emergente. Outra implicação é que o papel específico que uma parte de um composto desempenha pode significar que se devem formar subclasses de uma classe de coisas para refletir diferentes papéis. Um exemplo, dado por WAND et al. (1999) e mostrado na Figura 3.5, seriam de pessoas que podem fazer parte de um time, desempenhado diferentes papéis: uma pessoa poderia ser o líder do time e outras pessoas seriam apenas membros regulares.
Figura 3.5 – Utilização de subtipos participando de relacionamentos “parte-de” obrigatórios. Fonte: WAND et al. (1999).
Membro Time Parte-de Líder Time Pessoa Time Parte-de 1.. 1.. 1.. 1..
