Benchmark Equipment

Esta seção discute brevemente abordagens que compartilham semelhanças com as características presentes neste trabalho referente à definição de linguagem formal subjacente a programas lógicos, ao tratamento de ontologias e ao uso de metamodelagem para descrição de conceitos.

3.4.1 Telos

Telos é um exemplo de linguagem declarativa para representação do conhecimento construída no final dos anos 1980 e início dos 1990 como uma proposta de formalização de redes semânticas (MYLOPOULOS et al.,1990;MYLOPOULOS, 1992):

In a nutshell, the contribution of Telos lies in its adaptation of ideas from knowledge representation, deductive databases and requirements modeling languages in order to offer a language that can be used to tackle a broader class of modeling tasks – arising from information system development tasks – than those attempted by other proposals (MYLOPOULOS et al., 1990, p. 359)13_.

Telos é uma linguagem com alta expressividade, orientada a frames, que permite a declaração de classes, propriedades de classes como atributos de primeira ordem, tokens e relações. Como exemplos de relações, destacam-se relações de subsunção e instanciação (de uma classe por um token). A linguagem permite também a declaração de dados temporais, caso que inclui uma característica modal às instâncias de classes. Além disso, é possível a especificação de restrições (constraints) tanto referentes à cardinalidade e multiplicidade de relações quanto referentes às instâncias e outras relações formais das estruturas descritas na linguagem. Nesse caso, uma sintaxe com operadores que lembram uma linguagem de primeira ordem é usada. Uma característica interessante do Telos é a possibilidade de declarar instâncias em diferentes níveis. Ou seja, uma instância de uma classe pode ser uma classe para outra instância. Essa é uma característica semelhante às instâncias entre camadas da UML. A sintaxe proposta pela Human-Usable Textual Notation (HUTN) Specification (OBJECT MANAGEMENT GROUP, 2004), também baseada em frames, é semelhante à sintaxe do Telos.

Publicações referentes ao Telos foram analisadas nesta pesquisa de modo a se herdar algumas características daquela linguagem, como as propriedades básicas das relações de 13 _{Conforme a obra citada, um protótipo do Telos foi implementado em Prolog no final dos anos 1980.}

3.4. Abordagens similares 121

subsunção e instanciação, e o fato de relacionamentos não serem elementos de primeira classe na linguagem. Embora tenha servido de referência, Telos não é aplicado diretamente nessa pesquisa porque os objetivos deste trabalho não seria completamente atendidos com essa ferramenta. Especialmente, as características modais necessárias à formalização de ontologias de forma colaborativa não poderiam ser descritas por meio das regras temporais modais embutidas em Telos, uma vez que deseja-se explorar semânticas modais com interpretações epistêmicas/doxásticas de vários agentes.

3.4.2 OntoDSL

No contexto de propostas de definição de semântica de linguagens,Walter, Parreiras e Staab (2009) eWalter (2009) desenvolvem uma proposta chamada OntoDSL. Segundo os autores, OntoDSL consiste em uma abordagem que permite o uso de ontologias para descrever DSL. Essencialmente, usam uma abordagem em camadas (M3), na qual na M1 estão as instâncias de modelos de domínio desenvolvidas por usuários da DSL. Na M2 estão as operações possíveis e a semântica formal da DSL. É nesta camada que o designer da DSL define efetivamente a sintaxe linguagem. Ambas as camadas, M1 e M2, são transformadas em descrições em Lógica Descritiva por meio de ABox e TBox, respectivamente. Por fim, na M3 concentra-se os metametamodelos usados para construir as demais camadas. Os autores propõem o uso de KM3 (JOUAULT; BÉZIVIN, 2006) – um subconjunto simplificado de MOF (OBJECT MANAGEMENT GROUP, 2014a) – para definir a estrutura sintática da linguagem, OWL2 (W3C,2012) para definir sua semântica e OCL (ISO/IEC,2012b) para as operações. A Figura 4 ilustra a abordagem dos autores.

Figura 4 – Camadas do OntoDSL Integrated Metametamodel M3 M2 M1 DSL Metamodel Domain Model Domain Model instanceOf instanceOf instanceOf KM3 OWL2 DSL Designer DSL User Formal Semantics OWL Ontology instanceOf ABox TBox transform transform Reasoning Service OCL Operation

Fonte: Walter, Parreiras e Staab(2009)

Entre os pontos positivos que se pode destacar na abordagem, está a integração com as tecnologias correntes propostas pela W3C (OWL2, OCL), que possuem um vasto número de ferramentas e de fornecedores, o que é reflexo de grande aceitação no mercado. O principal ponto negativo talvez se refira a críticas à referentes aos requisitos impostos à OWL: apenas um fragmento decidível das lógicas são incorporadas as suas tecnologias, o que limita os resultados à apenas uma parte das variadas possibilidades oferecidas

pelos avanços teóricos da Lógica, muitos deles já disponíveis para uso, como banco de dados dedutivos paraconsistentes (PAIS, 2004; AMO; PAIS, 2007), Programação em Lógica Modal (NGUYEN, 1999; NGUYEN, 2001; NGUYEN, 2009), entre outras. Crítica semelhante é realizada porStörrle (2007b, p. 73) no que tange ao uso de OCL:

The OCL is somewhat more general in that, theoretically, it should fit to any UML model/tool combination. In practical settings, this is not true, however. Also, OCL is extremely difficult to read and write and there is very scarce tool support (STÖRRLE,2007b, p. 73).

A proposta do OntoDSL é justificada pelos criadores como uma abordagem que visa resolver desafios na construção de linguagens específicas de domínio. Baseado emGray et al. (2008), os autores argumentam que são cinco os desafios principais na construção de DSL:

a) Desafio 1: Ferramentas (“debuggers”, ferramentas de teste); b) Desafio 2: Interoperabilidade com outras linguagens;

c) Desafio 3: Semântica formal; d) Desafio 4: Curva de aprendizagem;

e) Desafio 5: Análise de domínio.

Para atender o terceiro desafio,Walter, Parreiras e Staabmencionam queGuizzardi, Pires e Sinderen (2006) propõem o uso de “upper ontologies” para desenhar e avaliar conceitos de domínio. De fato, o artigo citado, que é baseado nos primeiros capítulos da tese do autor (GUIZZARDI, 2005), discorre sobre um método baseado em ontologia para avaliar domain-specific visual modeling languages (DSVL), que é um tipo de DSL focado em linguagens visuais. Para Guizzardi(2006), há pelo menos dois critérios importantes a serem considerados na avaliação de linguagens desse tipo:

(i) it should easy for a user of the language to communicate, understand and reason with the produced models (comprehensibility appropriateness); (ii) The language should be truthful to the domain in reality that it is supposed to represent (domain appropriateness).

No contexto de DSVL, do ponto de vista pragmático a separação entre sintaxe e semântica é muito mais tênue do que no caso de linguagens baseadas em frases, uma vez que aquelas, idealmente, devem embutir na representação concreta visual aspectos semânticos em relação ao domínio que se planeja modelar. Ou seja, no caso das DSVL, a sintaxe visual pode explorar a capacidade de informar o usuário sobre aspectos semânticos do domínio que aquela linguagem se presta a descrever. Essa característica, quando explorada cuidadosamente de modo a considerar símbolos significativos e não ambíguos, possui a vantagem de melhorar a compreensão das construções realizadas. Por outro lado, as

3.4. Abordagens similares 123

linguagens visuais, quando projetadas sem considerar o domínio específico e o significado que os símbolos possam induzir, possuem o risco de produzir significados indesejados e ambíguos.

3.4.3 MoMaT

Há diversos trabalhos que investigam a verificação de modelos UML e de OCL em Prolog (PAP; PATARICZA; SZEGI, 2001; MOTA et al., 2003; CHIMIAK-OPOKA et al., 2008;KHAI; NADEEM; LEE, 2011; ZARETSKA et al., 2012). Para apresentar um exemplo, em Störrle (2007b) e em Störrle (2007a) desenvolve-se um sistema batizado de Model Manipulation Toolkit ( MoMaT):

Over the last years, we have created a system called the Model Manip- ulation Toolkit (MoMaT) which allows us to experiment with models in general. In MoMaT, models are imported into a Prolog-based model repository by a set of transformers for several modeling languages like UML, ARIS/EPC, and Use Case Maps (in this paper, we will only focus on UML models, though) (STÖRRLE,2007b, p. 72).

O autor propõe um modelo de representação em Prologe uma interface de consulta para análise de modelos na abordagem MDD (Model Driven Development). No MoMat, modelos e consultas são representados em cláusulas padrões Prolog. Pode-se realizar consul- tas sobre essas bases de fatos de modo a identificar elementos, propriedades e submodelos. As representações do autor são em forma de listas de mapas de classes, propriedades e operações de classes. A proposta é interessante, porque permite a identificação de dife- rentes versões dos objetos, numa semântica temporal. Uma característica do MoMat é a possibilidade de se trabalhar com diferentes tipos de modelos, e não apenas modelos baseados nos padrões da OMG ou W3C. Para isso, uma etapa de conversão de modelos padroniza a forma dos dados para fatos Prolog, de modo que esse padrão funcione como semântica comum para os diferentes modelos. A Figura 5 ilustra esse processo.

Já aFigura 6 apresenta uma visão esquemática do MoMat, em que se destacam as funcionalidades da ferramenta, salientada a capacidade de realização de consultas.

A abordagem geral realizada no MoMat serviu de referência para o desenvolvimento do Ontoprolog, especialmente no que se refere à representação de dados de modelos baseados em Programação em Lógica, e as características de realização de consultas à base de fatos que representa os discursos sobre ontologias.

Figura 5 – Classes de operações sobre diagramas potencialmente relevantes para modela- gem industrial Model Management Model Repository Model Probing Model Validaon Compilaon & Genera�on

Model Verificaon Model Manipulaon

che ck c_on sis tenc_y anal yse quan t av ely type che_{ck in} scrip_ons input / load / stor e trans form / obfu scate edit/ la yout impor t /ex port compar e /ex tract merge / diff / patc h query _check syntax measur e rep_ort prog ram code mod elfr_ag men_ts exe_cut e / test enac t /si mu_late inspe ct Fonte:Störrle(2007b, p. 72)

Figura 6 – Visão esquemática do MoMaT

Model Repository (Prolog Facts) CDMoMaT Meta-Metamodel (M3) ModelElement Value BasicValue Set List {ordered} * * Int Model id: int 1 tag: string

Char Bool {unique} Reference id: int ModelProperes View 1 * Adonis / UML Fujaba / UML 1.5

MagicDraw / UML 2Sparx EA / UML 2

ADL MDL Rose / UML 1.3 specific file format modeling tools XMI 1.x XMI 2 Adonis / EPC specific converters M3_format generic converter Original (concept, system) XMI 2' XMI 1.x' me(class-42, [name-'A', ...]). Fonte:Störrle(2007b, p. 72)

3.5 Estilos de Programação em Lógica

Embora seja uma linguagem quase quadragenária, apenas em2012 foi publicado um artigo inteiramente dedicado a sugerir um estilo consistente de codificação para Prolog. O artigo referido trata-se do trabalho de Covington et al. (2012), que é a evolução de um rascunho não publicado, mas disponível online (COVINGTON, 2002), escrito uma década antes. O texto é um guia de estilos de orientações gerais de codificação em Prolog e consiste em sugestões de boas práticas baseadas na experiência dos próprios autores e também baseadas no clássico livro estilos de programação deKernighan e Plauger (1978) – que apresenta exemplos em PL/I e em Fortran – e em uma obra mais recente do autor (KERNIGHAN; PIKE, 2009) – em que já são apresentados exemplos em Java, embora não seja um livro dedicado exclusivamente aos estilos de programação. O guia de Covington et al.é composto por 17 sugestões referentes a layout do código, 14 referentes a convenção de

3.6. Fechamento 125

nomes, 5 sobre documentação, 13 dedicadas a detalhes da linguagem e 18 gerais, referentes ao desenvolvimento, teste e depuração.

Os estilos de programação são importantes porque simplificam a leitura do código por tentar impor um determinado modo de codificação que não desvie o foco de um leitor da lógica e da linha de raciocínio denotadas pelo programa. Porém, a definição de regras de estilos de programação trata-se também de arte, e não somente de ciência, uma vez que não é possível estabelecer um padrão único, pré-determinado, adequado para todas as situações ou claro o suficiente para que seja possível apresentar argumentos puramente lógicos que justifiquem sua escolha. Nesse sentido, por envolverem arte e ciência, poderia ser argumentado que se tratam de um aspecto de “arquitetura”14_{, no caso, algo como a} “arquitetura do estilo de programação”.

Todos os códigos Prolog presentes neste texto, e componentes dos softwares produ- zidos nesta pesquisa (Capítulo 10), são produzidos considerando as sugestões deCovington et al. (2012), embora não necessariamente se atenda a todas as recomendações dos autores. Quando isso não acontece, fica evidenciado o fragmento não científico inerente ao arbítrio da proposta.

Opta-se por não incluir neste texto as sugestões em si dos autores, uma vez que tratam-se de demasiados detalhes sobre os quais não se pretende dissertar, apenas seguir e cumprir conformidade. De toda forma, as sugestões se presam ao objetivo de ter um padrão de qualidade a ser seguido. Além disso, o artigo referido está disponível online, conforme entrada das Referências.

3.6 Fechamento

Destaca-se que no contexto da seção 3.1, a subseção 3.1.2 apresenta definições, baseadas emLloyd(1993), que visam introduzir a anotação das formulações lógicas utilizada no restante deste trabalho. Essas definições são realizadas com intuito de construir uma ligação da notação padrão de Lógica Clássica de Primeira Ordem com a notação comumente utilizada na Programação em Lógica, baseada em cláusulas de Horn.

A semantic embedding, proposta para Prolog porArmstrong, Virding e Williams (1992), abordada na seção 3.3, é o tipo de semântica utilizada neste trabalho, conforme mencionado naseção 6.1. Isso ocorre porque utiliza-se as semânticas atribuídas a programas Prolog, como a semântica baseada em modelos de Herbrand, como significado das relações do universo semântico das sentenças sintáticas de Ontoprolog.

O nome função filtro, usado no título da seção 7.3, é obtido de Gupta (1998), 14 _{Argumentos que objetivam justificar a ideia de arquitetura como (a intersecção entre) arte e ciência}

é apresentado, por exemplo, porCosta(2003, p. 19-21), Winters(2007, p. 162),Castelnou(2011) e outros arquitetos citados emAraujo(2012, p. 65-74).

também abordado naseção 3.3. Porém, não apenas o título, mas a abordagem do autor para atribuição de semântica de sintaxe de linguagem é de fato a utilizada nas definições do significado da sintaxe de Ontoprolog em termos relações semânticas de Prolog puro, conforme descrito naquela seção.

A estratégia de Kosar e Mernik e de Decker é a adotada neste trabalho no que se refere à definição de Ontoprolog como uma DSL interna em Prolog construída por meio de operadores. A semântica dessas construções via operadores é dada como tradução (filtro) para o domínio semântico da linguagem Prolog (semantic embedding), o que inclui

a semântica de base de dados (subseção 3.1.4), conforme detalhado na Parte III.

Quando a MProlog, de modo geral seu é justificado no caso de prototipagem de lógicas que estabeleçam relações de dedução modal. O arcabouço lógico apresentado brevemente na seção 3.2 é utilizado como sustentação de lógicas subjacentes à extensão modal da linguagem de especificação de ontologias produzida nesta pesquisa. Isso é realizado noCapítulo 9.

127