ViXQueL: uma ferramenta web para acesso a banco de dados XML nativo

Texto

(1)Universidade Federal de Pernambuco Centro de Informática. Pós-graduação em Ciência da Computação. VIXQUEL: UMA FERRAMENTA VISUAL WEB PARA ACESSO A BANCO DE DADOS XML NATIVO Petrus Rangel Bastos Dissertação de Mestrado. Recife Fevereiro de 2009.

(2) Universidade Federal de Pernambuco Centro de Informática. Petrus Rangel Bastos. VIXQUEL: UMA FERRAMENTA VISUAL WEB PARA ACESSO A BANCO DE DADOS XML NATIVO. Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.. Orientador: Prof. Dr. Roberto Souto Maior de Barros Co-orientador: Prof. Dr. Fernando da Fonseca de Souza. Recife Fevereiro de 2009.

(3) Bastos, Petrus Rangel ViXQueL: uma ferramenta web para acesso a banco de dados XML nativo / Petrus Rangel Bastos Recife : O Autor, 2009. x, 104 folhas : il., fig., quadros Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2009. Inclui bibliografia. 1. Banco de dados. 2. Engenharia de software. I. Título. 025.04. CDD (22. ed.). MEI2009-042.

(4) Agradecimentos. Agradeço aos professores Roberto Barros e Fernando Fonseca, pelo cuidado e dedicação com que me acompanharam, desde o início, na trajetória desta etapa tão importante para a minha vida. Além destes, gostaria de agradecer a todos os professores da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco que de alguma forma participaram desta caminhada. Agradeço aos meus pais Carmelo José Albanez Bastos e Rachel Rangel de Farias Albanez Bastos pelos ensinamentos eternos de honestidade e perseverança. Estendo este agradecimento aos meus irmãos Carmelo José Albanez Bastos Filho e Angelica Rangel Bastos por todo o incentivo e atenção prestados durante este período. Agradeço à minha noiva, muito em breve esposa, Viviann Silveira de Albuquerque, pelo carinho, força e companheirismo nas horas mais difíceis. Por entender as faltas e apoiar em todos os momentos, sem fraquejar ao menos uma vez. Agradeço aos amigos Rafael Jacinto e Eduardo Matos pelas infindáveis discussões, implementações e pesquisa. Agradeço a todos os amigos do mestrado, em especial Joel da Silva, por todos os momentos compartilhados, que foram de suma importância para trilhar este caminho. Agradeço ao professor Antônio Mendes da Silva Filho pelo voto de confiança que me permitiu chegar até aqui. Agradeço ao amigo russo Ivan Shcheklein, um dos desenvolvedores do SGBD XML nativo Sedna, pelos diversos auxílios e esclarecimentos sobre a linguagem XQuery. A todos um muito obrigado! Sem vocês esta conquista não seria possível!. iii.

(5) Resumo. XML tornou-se o padrão de fato para troca de informações entre diversas fontes de dados e aplicações. Assim, sistemas de gerenciamento de bancos de dados XML nativos (SGBD XML nativos) têm se tornado peça fundamental na infra-estrutura de empresas que lidam com tal diversidade de fontes de dados e aplicações. Gestores do mundo corporativo estão sempre precisando de informações sobre seus negócios, para que possam tomar decisões de forma rápida e eficiente. Entretanto, as interfaces gráficas disponíveis para recuperar estas informações não demonstram preocupação com esta classe de usuários, disponibilizando apenas interfaces textuais que os obrigam a ter conhecimento nas linguagens de consulta para XML, mais especificamente a XQuery. Visando contribuir para a melhoria desta situação, este trabalho apresenta a ViXQueL, que é uma ferramenta web de abstração para acesso aos SGBD XML nativos, permitindo que usuários não especialistas recuperem informações de bases de dados sem conhecimento na linguagem de consulta XQuery. Esta abstração foi alcançada por meio de uma interface gráfica para criação de consultas visuais, que por sua vez são transformadas em consultas textuais na linguagem XQuery. Devido à extensividade e complexidade, o protótipo desenvolvido permite a criação de consultas que representam um subconjunto da XQuery. Para a primeira versão da ferramenta foram considerados e avaliados diversos SGBD XML nativos, sendo escolhido o Sedna, por sua completude de funcionalidades, além de ser open source. Com o intuito de formalizar o processo de transformação da ferramenta, foram utilizados conceitos de MDA na definição e implementação do processo de geração do código XQuery. Dois metamodelos foram especificados em Ecore, que é a implementação de metamodelagem do Eclipse Modeling Framework (EMF), para representar as consultas visuais e as consultas textuais. Além disso, foram implementados dois scripts, na linguagem Kermeta, para realizar as transformações necessárias entre instâncias destes metamodelos. Palavras-chave: XQuery, XML, SGBD XML nativo, Sedna, MDA.. iv.

(6) Abstract. XML has become a standard for information exchange between various data sources and applications. Thus, native XML database management systems are playing an important role in companies’ infrastructure to deal with a diversity of such sources/applications. Managers of the corporate world always need information about their business, so they can make decisions quickly and efficiently. However, the graphical interfaces available to retrieve those information do not show concern for this class of users, offering textual interfaces only and requiring them to have knowledge of languages to query XML, more specifically the XQuery. To help improving this situation, this work presents the ViXQueL, which is a web tool to abstract native XML DBMS access, allowing non-specialists users to retrieve information from databases without knowledge of the XQuery query language. This abstraction was achieved through a graphical interface for creating visual queries, which in turn are converted into textual queries written in XQuery. Due to the extensiveness and complexity, the developed tool allows for the creation of queries that represent a subset of XQuery. For the first prototype of the tool various native XML DBMS were considered and evaluated, and the Sedna was chosen, for its completeness of features, and because it is open source. In order to formalize the tool transformation process, MDA concepts have been used in the definition and implementation of the XQuery code generation. Two metamodels were specified in Ecore, which is the metamodeling implementation of Eclipse Modeling Framework (EMF), to represent visual queries and textual queries. In addition, two scripts were implemented in the Kermeta language to carry out the necessary transformations between instances of these metamodels. Keywords: XQuery, XML, Native XML DBMS, Sedna, MDA.. v.

(7) Sumário. 1. Introdução 1.1 Motivação 1.2 Objetivos 1.3 Estrutura da Dissertação. 1 2 3 4. 2. Fundamentação Conceitual 2.1 SGBD XML nativos 2.1.1 Conceitos 2.1.2 Ferramentas 2.1.3 Aplicações 2.2 Orientação a modelos 2.2.1 DSM - Modelagem específica de domínio 2.2.2 Metamodelagem 2.2.3 MOF - Meta Object Facility 2.2.4 MDA - Arquitetura dirigida a modelos 2.2.5 XMI - XML Metadata Interchange 2.3 Considerações Finais. 6 7 7 8 10 14 14 15 16 17 19 22. 3. Trabalhos relacionados 3.1 Introdução 3.2 XQBE 3.3 GXQL 3.4 BBQ 3.5 XQueryViz 3.6 XGI 3.7 Considerações Finais. 24 25 26 28 29 31 33 35. 4. ViXQueL 4.1 Funcionalidade 4.2 Arquitetura 4.3 O sistema 4.4 A geração do código XQuery 4.4.1 Metamodelos 4.4.2 Transformações entre modelos 4.5 Expressividade da ViXQueL 4.6 Considerações Finais. 37 38 39 41 46 46 52 58 59. vi.

(8) SUMÁRIO. vii. 5. Estudo de Caso 5.1 Domínio de Problema 5.2 Exemplo do processo de criação de consultas 5.2.1 Preparação do ambiente para criação de consultas 5.2.2 Passo a passo da criação de um exemplo de acordo com a visão do usuário 5.2.3 Passo a passo do processo de transformação 5.3 Consultas 5.3.1 Conjunção 5.3.2 Projeção em largura 5.3.3 Projeção em profundidade 5.3.4 Ordenação 5.3.5 Consultas envolvendo diversas categorias 5.4 Avaliação Preliminar 5.5 Considerações Finais. 61 62 67 67 69 75 78 80 81 82 83 84 86 87. 6. Conclusões e Trabalhos Futuros 6.1 Introdução 6.2 Conclusões e Contribuições 6.3 Limitações e Trabalhos Futuros. 89 90 90 92.

(9) Lista de Figuras. 2.1 2.2 2.3. Ciclo de vida do MDA. Cabeçalho de um documento XMI. Conteúdo de um documento XMI.. 20 21 22. 3.1 3.2 3.3 3.4 3.5. Interface gráfica da ferramenta XQBE. Interface gráfica da ferramenta GXQL. Interface gráfica da ferramenta BBQ. Interface gráfica da ferramenta XQueryViz. Interface gráfica da ferramenta XGI.. 27 29 30 32 34. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12. Arquitetura da ferramenta ViXQueL. Diagrama de classes da ViXQueL. Tela de gerenciamento de conectividade da ViXQueL. Tela de gerenciamento de bases de dados. Tela de criação de consultas. Diagrama de estrutura do metamodelo ViXQueL. Exemplo de um modelo da ViXQueL. Diagrama de estrutura do metamodelo XQuery. Exemplo de um modelo da XQuery. Trecho de código da transformação ViXQueL2XQuery.kmt. Trecho de código da transformação XQuery2Code.kmt. Processo de transformação da ViXQueL para código XQuery.. 39 42 42 43 44 48 48 51 52 55 56 57. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13. Diagrama estrutural da biblioteca. Trecho do XML Schema da biblioteca que define o elemento raiz. Trecho do XML Schema da biblioteca que define o elemento livro. Trecho do XML Schema da biblioteca que define o elemento artigo. Trecho do XML Schema da biblioteca que define o elemento revista. Trecho do XML Schema da biblioteca que define o restante dos elementos. Exemplo de arquivo XML de acordo com o XML Schema do estudo de caso. Etapa 1 do processo de preparação do ambiente. Etapa 2 do processo de preparação do ambiente. Tela inicial para a construção de consultas visuais. Situação visual da consulta após o primeiro passo da construção. Situação da consulta após o segundo passo da construção. Situação da consulta após o terceiro passo da construção.. 62 63 63 64 64 65 66 68 69 70 71 72 72. viii.

(10) LISTA DE FIGURAS. 5.14 5.15 5.16 5.17 5.18. Situação da consulta após o quarto passo da construção. Resultado final da criação do exemplo de consulta. Modelo ViXQueL referente a consulta da subseção 5.2.2. Modelo XQuery referente a consulta da subseção 5.2.2. Código XQuery referente a consulta da subseção 5.2.2.. ix 73 74 76 77 78.

(11) Lista de Quadros. 2.1 2.2. Resumo comparativo entre os SGBD XML nativos. Arquitetura em camadas do MOF. 9 16. 3.1. Resumo das características avaliadas dos trabalhos relacionados.. 36. 4.1. Funcionalidades da XQuery suportadas pela ViXQueL.. 58. 5.1 5.2 5.3 5.4 5.5 5.6. Informações sobre a consulta q1. Informações sobre a consulta q2. Informações sobre a consulta q3. Informações sobre a consulta q4. Informações sobre a consulta q5. Informações sobre a consulta q6.. 80 81 82 83 84 85. x.

(12) C APÍTULO 1 Introdução. Este capítulo relata as principais motivações para realização deste trabalho, lista os objetivos de pesquisa almejados, além de mostrar como está estruturado o restante da presente dissertação.. 1.

(13) 1.1 MOTIVAÇÃO. 1.1. 2. Motivação. Devido à rápida movimentação do mundo corporativo, geralmente os gestores necessitam de informações precisas sobre o negócio de forma rápida e eficiente ao alcance de suas mãos, para assim poder realizar a tomada de decisão da forma mais eficaz possível. Desta maneira, não há nada melhor para o gestor do que a possibilidade dele mesmo recuperar tal informação, sem depender de nenhum especialista da área de informática. Para que uma determinada informação esteja disponível, muitas vezes é necessário que haja uma integração de diversas fontes de dados. Assim, o uso de XML [W3C08d] tornou-se uma maneira eficaz de integrar tais fontes de dados, visto que atualmente já se pode considerá-la como o padrão de fato para troca de informações entre fontes de dados e aplicações [NLB+ 02]. A crescente necessidade de armazenar e processar documentos XML exigiu o desenvolvimento de mecanismos sistemáticos e eficientes para realizar tais tarefas. Assim, surgiram os Sistemas de Gerenciamento de Bancos de Dados XML nativos (SGBD XML nativos) [FHK+ 02]. O primeiro SGBD XML nativo a surgir foi o Tamino [AG07], desenvolvido pela empresa Software AG, logo seguido por outros [Sie04]. Existem atualmente mais de 40 SGBD XML nativos, atrelados a diversas formas de licenças, inclusive comerciais e open source [Bou07b]. Juntamente a esta grande variedade de SGBD XML nativos, vêm surgindo diversas ferramentas para administração, desenvolvimento e manipulação de bases de dados. Entretanto, todas as ferramentas existentes na literatura requerem que os usuários tenham algum grau de conhecimento nas tecnologias relacionadas a XML, para de fato poderem se beneficiar destas ferramentas. Embora existam algumas ferramentas que despendem certa preocupação com os usuários não especialistas, não há na literatura, até o momento, nenhuma ferramenta que permita seu uso sem nenhum conhecimento em tecnologias relacionadas a XML. Além do mais, o fato de que nenhuma destas ferramentas está acoplada a um SGBD XML nativo aumenta suas limitações, pois não permite aproveitar todas as funcionalidades já consolidadas de um SGBD tradicio-.

(14) 1.2 OBJETIVOS. 3. nal, tais como, controle de concorrência, segurança, gerenciamento de transações, entre outros. Além disto, esta situação, resulta ainda em outros problemas como, por exemplo, escalabilidade, dado que apenas com tal tipo de SGBD pode-se lidar com milhões de documentos de maneira satisfatória, sem degradar o sistema rapidamente. Assim, surgiu a idéia de desenvolver uma maneira estruturada, simples e intuitiva para que os próprios gestores sejam capazes de recuperar informações que sejam importantes para o processo de tomada de decisões estratégicas.. 1.2. Objetivos. Este trabalho tem por objetivo geral apresentar uma solução eficiente ao problema citado anteriormente. Assim, apresenta-se a ViXQuel, uma ferramenta visual para facilitar o acesso a SGBD XML nativos. De modo geral, a ferramenta se propõe a facilitar o acesso de seus usuários a informações contidas em bases de dados XML. Através do uso de um ambiente WEB visual, a ferramenta proposta permite que o usuário acesse tais informações mesmo que não tenha nenhum conhecimento de tecnologias relacionadas a XML. A ferramenta foi projetada para funcionar em ambiente WEB visando a facilidade que este tipo de ambiente fornece para a criação de aplicações dinâmicas que representam um novo modelo de cooperação e colaboração entre uma vasta quantidade de usuários [Jaz07]. Ainda como parte da solução proposta, a ferramenta fornece uma forma estruturada de realizar a transformação da consulta visual para uma consulta XQuery [W3C08h], realizando validações da expressão gerada e facilitando a compreensão por parte dos estudiosos na área de sintaxe e semântica da linguagem. Com o intuito de atingir o objetivo geral deste trabalho, foi necessário definir alguns objetivos específicos: • Estudar e analisar as ferramentas relacionadas, de forma a identificar as suas deficiências;.

(15) 1.3 ESTRUTURA DA DISSERTAÇÃO. 4. • Projetar uma arquitetura que atenda a todas as necessidades do protótipo da ferramenta; • Realizar testes de validação e avaliação entre a ferramenta proposta e as ferramentas existentes; • Consolidar os dados dos testes e apontar os ganhos obtidos com a nova abordagem.. 1.3. Estrutura da Dissertação. Além deste capítulo introdutório, no qual foram apresentadas a motivação e os objetivos da ferramenta proposta, esta dissertação é composta por mais cinco capítulos, como segue. O Capítulo 2, Fundamentação Conceitual, aborda os conceitos básicos necessários para o entendimento deste trabalho. Este capítulo está dividido em duas grandes partes. A primeira parte apresenta uma visão geral das tecnologias existentes na área de sistemas de bancos de dados XML nativos, incluindo conceitos, ferramentas e aplicações relacionadas. A segunda parte aborda os conceitos relacionados ao desenvolvimento orientado a modelos, além das tecnologias e ferramentas associadas. O Capítulo 3, Trabalhos Relacionados, trata das abordagens relacionadas, fornecendo um panorama geral das principais ferramentas existentes. Inicialmente, são descritas as principais abordagens referenciadas na literatura que compartilham a mesma preocupação deste trabalho, e que fornecem estratégias distintas para o tratamento do problema. Por fim, realiza uma análise destes trabalhos e aponta limitações em comum. O Capítulo 4, VixQueL, apresenta o protótipo da ferramenta como uma proposta de solução para o problema. O capítulo se inicia com uma visão geral do que é a ferramenta e como ela foi concebida e, posteriormente, são explanadas as principais funcionalidades da mesma. Por fim, são apresentados a arquitetura da ferramenta e os detalhes de implementação. O Capítulo 5, Estudo de Caso, apresenta um estudo de caso para mostrar o uso real da ferramenta em um determinado domínio de problema. O capítulo se inicia descrevendo o domínio.

(16) 1.3 ESTRUTURA DA DISSERTAÇÃO. 5. de problema utilizado. Logo após, é apresentado um passo a passo completo do processo de criação de uma consulta. Posteriormente, é apresentado um conjunto de consultas categorizadas que podem ser realizadas naquele domínio. Por fim, é apresentada uma avaliação preliminar da ferramenta com três grupos de usuários com diferentes graus de conhecimento. O Capítulo 6, Conclusões e Trabalhos Futuros, apresenta as conclusões do trabalho com um breve resumo dos resultados obtidos, dificuldades encontradas e principais contribuições, além de apontar as limitações e propostas de trabalhos futuros..

(17) C APÍTULO 2 Fundamentação Conceitual. Este capítulo tem por objetivo abordar conceitos fundamentais para o desenvolvimento deste trabalho. O capítulo se inicia explicando conceitos sobre SGBD XML nativos, além de ferramentas e aplicações. Por fim, aborda conceitos relacionados a metamodelos, desenvolvimento dirigido a modelos e transformação de modelos.. 6.

(18) 2.1 SGBD XML NATIVOS. 2.1. 7. SGBD XML nativos. Os SGBD XML nativos têm sido bastante utilizados em grandes empresas para auxiliar na resolução de diversos tipos de problemas. Esta seção apresenta o porquê do surgimento deste tipo de SGBD, bem como discute sobre as ferramentas associadas mais importantes. Por fim, apresenta diversos casos de uso em corporações multinacionais.. 2.1.1. Conceitos. Um sistema de gerenciamento de banco de dados (SGBD) é a base de grande parte dos sistemas de informação. Na prática, a maior parte dos sistemas de informação se utiliza de uma base de dados [CDPT98]. Dada esta necessidade, surgiram vários SGBD para suprir as necessidades de armazenamento e manipulação dos dados destes sistemas de informação. Alguns destes SGBD mais conhecidos são Oracle [Ora08a], DB2 [DB208], SQL Server [Mic08d] e PostgreSQL [Pos08]. Com o crescente uso de XML surgiu a necessidade de uma forma mais organizada e segura de se lidar com o mesmo. Assim, os SGBD tradicionais começaram a fornecer suporte de armazenamento e recuperação de dados XML, principalmente depois da definição do padrão ISO/IEC 9075-14:2003 [ISO04] que especifica formas sob as quais a linguagem SQL pode ser utilizada em conjunto com XML. Embora essa nova funcionalidade dos SGBD tenha sido um grande avanço para o armazenamento e manipulação de documentos XML, o problema ainda não havia sido resolvido completamente, dada a deficiência em lidar com os documentos sem uma estrutura bem definida. Os documentos XML podem ser classificados em dois tipos: os centrados nos dados (datacentric) e os centrados nos documentos (document-centric) [NLB+ 02]. Os SGBD tradicionais apenas conseguem lidar de forma satisfatória com os documentos centrados em dados, pois eles têm uma estrutura bem definida, permitindo, por exemplo, que sejam mapeados em tabelas dos.

(19) 2.1 SGBD XML NATIVOS. 8. SGBD relacionais. A definição da estrutura dos documentos XML dá-se através de um DTD [W3C08c] ou XML Schema [W3C08g]. Com o intuito de suprir a deficiência dos SGBD tradicionais de não serem capazes de lidar com todos os tipos de documentos XML, foram desenvolvidos os sistemas de bancos de dados XML nativos, os quais diferem dos tradicionais em três principais aspectos. Em primeiro lugar, um banco de dados XML nativo preserva a estrutura física do documento, como: seções CDATA, comentários, instruções de processamento e DTD. Em segundo lugar, os bancos de dados XML nativos podem armazenar dados que não estejam relacionados a um esquema. Em terceiro lugar, as API relacionadas a XML, como por exemplo, SAX [OAS08] e DOM [W3C08b], devem ser utilizadas para acessar dados em um banco de dados XML nativo, diferentemente dos sistemas tradicionais que podem oferecer acesso direto aos dados através de API de padrão aberto, tais como open-database conectivity (ODBC) [NLB+ 02].. 2.1.2. Ferramentas. Atualmente, existem vários SGBD XML nativos, como pode ser observado em [Bou07b]. Existem, nesta lista, SGBD associados às mais diversas formas de licença. Dentre as soluções comerciais, as que mais se destacam são: Tamino [AG07], MarkLogic Server [Log08] e TextML Server [IXI08]. Apesar de grande parte dos SGBD mencionados em [Bou07b] serem comerciais, existem também diversas soluções open source, entre as quais se destacam o Sedna [MI08], o eXist [eXi08] e o Berkley DB XML [Ora08b]. Através do estudo dos SGBD disponíveis foi possível identificar que as soluções existentes têm características e funcionalidades bastante semelhantes. O Quadro 2.1 apresenta um resumo destes SGBD e suas funcionalidades. O TextML Server [IXI08] não foi incluído na avaliação pois não fornece suporte à XQuery, assim tornando-se inelegível para o uso neste trabalho..

(20) 2.1 SGBD XML NATIVOS. 9. Quadro 2.1: Resumo comparativo entre os SGBD XML nativos.. Funcionalidade Sedna eXist Berkeley Tamino Marklogic Suporta XQuery/XPath X X X X X Possui linguagem de UPDATE X X X X X Utiliza coleções X X X X X Suporta transações X X X X Possui pesquisa FULL TEXT X X X X Possui XML Triggers X X X X X Possui API XML:DB X X X Suporta o uso de XML Schema X X X X X Suporta arquitetura cliente/servidor X X X X API para linguagens de programação X X X X X Otimização de consultas X X X X X Segurança X X X X X. É claro que existem outras características e/ou funcionalidades que poderiam ter sido consideradas no Quadro 2.1, entretanto as características avaliadas são suficientes para dar o suporte necessário para o desenvolvimento deste trabalho. Através deste quadro foi possível eleger o SGBD XML nativo a ser utilizado na implementação deste trabalho. O Tamino e o Marklogic foram descartados por serem comerciais. Dentre as alternativas open source, o Sedna foi a alternativa que se mostrou mais completa, sendo assim eleito para ser utilizado na implementação deste trabalho. Além disto, o Sedna foi escolhido devido ao crescente interesse que está provocando entre os pesquisadores da área [AKNG06, ZTK06, CR07, SFM07]. Embora existam nesta lista SGBD associados às mais diversas formas de licença, nenhum deles alcançou ainda a devida maturidade no fornecimento de uma ferramenta que tenha a preocupação em fornecer funcionalidades que permitam aos usuários não-especialistas nas tecnologias relacionadas a XML se utilizarem deste tipo de SGBD. A situação se agrava quando tais funcionalidades estão associadas à recuperação e visualização de informações. Como um bom exemplo desta falta de preocupação com os usuários não-especialistas, pode-se citar a construção de uma consulta XQuery [W3C08h], pois nenhum SGBD XML nativo fornece uma forma amigável de construção de consultas em tal linguagem. Utilizando-.

(21) 2.1 SGBD XML NATIVOS. 10. se deste exemplo, a existência de uma ferramenta integrada permitiria que um usuário criasse uma consulta XQuery de forma intuitiva e amigável, e ainda pudesse determinar como o seu resultado seria exibido, utilizando-se mais facilmente de tecnologias relacionadas a XML como por exemplo, XSLT [W3C08i]. Embora os SGBD XML nativos já forneçam algumas funcionalidades que dão suporte ao seu uso, ainda existem muitas outras funcionalidades que poderiam ser exploradas pelos mesmos. Funcionalidades estas que permitiriam a usuários não-especialistas em tecnologias XML se utilizarem mais eficientemente do SGBD, além de aumentarem a produtividade de usuários especialistas.. 2.1.3. Aplicações. A partir de uma pesquisa realizada entre os principais fornecedores de SGBD XML nativos, foi possível identificar o uso mais comum para tal tipo de SGBD, sendo este o armazenamento e consulta a documentos XML centrados em documentos. Este fato já era de se imaginar, visto que esta é a grande deficiência dos SGBD tradicionais quando se trata de dados no formato XML. Abaixo seguem alguns exemplos de como SGBD XML nativos podem ser utilizados com documentos XML centrados em documentos. É importante ressaltar que todos os exemplos comentados nesta seção foram adaptados de [Bou07a]. • A Elsevier Science, editora de informações científicas, técnicas e médicas, utiliza o Mark Logic Server [Log08] para gerenciar mais de 2 terabytes de dados: aproximadamente 5 milhões de artigos completos de jornais, 60 milhões de citações e resumos, milhares de livros completos e 5 mil panfletos informacionais; • Uma grande variedade de aplicações de gerenciamento de conteúdo é construída sobre o TEXTML Server [IXI08] da IXIASOFT. Por exemplo, sistemas editoriais de terceiros tais como Eurocortex [Tec08a], KnowledgeView [Ltd08], Protec [Med08], Rosebud.

(22) 2.1 SGBD XML NATIVOS. 11. [Tec08b], Modulo [Sys08] e PCI [Inc08] usam-no para gerenciar produção, arquivar conteúdo, ou ambos, e estão instalados na maioria das editoras dos Estados Unidos e da Europa; • Amirsys usa o Ipedo XML Store [Ipe08] para gerenciar descrições de casos de diagnósticos de tratamento por radiação, dados de imagens, e dados usados para guiar um editor de documentos. O editor é projetado para escrita de livros sobre radiologia e apresenta funcionalidades, tais como consultas em descrições existentes e a habilidade de inserir imagens. Os livros são publicados usando o Apache FOP [Apa08a]. Além do mais, gerentes podem consultar documentos de forma a rastrear o progresso dos autores ou verificar se os elementos estão sendo utilizados da mesma forma pelos autores; e • O jornal Le Monde usa o Xyleme XML Server [Xyl08] para gerenciar um arquivo que contém mais de 800.000 documentos e usa 6 gigabytes de armazenamento. O arquivo é utilizado por empregados, parceiros e clientes. O segundo maior uso de SGBD XML nativos é na integração de dados. XML se adequa perfeitamente à integração de dados por causa do seu modelo de dados flexível. Além do mais, XQuery é uma boa linguagem para integração de dados, por causa da sua facilidade de uso, suporte a transformações e habilidade de juntar dados de diferentes fontes. Finalmente, existe um grande número de ferramentas para converter dados de vários formatos para XML. Abaixo seguem alguns exemplos de como SGBD XML nativos podem ser utilizados na integração de dados: • Dados de negócios A Vodafone usa o Tamino [AG07] em um sistema que permite que clientes e usuários internos vejam na web informações de faturamento. O sistema integra dados do SAP [SAP08], Lotus Notes [IBM08] e Microsoft Exchange [Mic08b]. O X-Hive/DB [Cor07] é usado de maneira similar, integrando dados de plataformas variadas, tais como: bancos.

(23) 2.1 SGBD XML NATIVOS. 12. de dados relacionais, arquivos de texto, Web Services, LDAP e sistemas HRM (Human Resource Management) para dar uma única visão de entidades, tais como clientes e produtos. • Análise de vendas A HP usa o Ipedo [Ipe08] para integrar dados financeiros internos, tais como pedidos, estoque, receitas, despesas, projeções financeiras e metas. Estes dados são reunidos de uma variedade de fontes, incluindo bancos de dados relacionais, planilhas eletrônicas, arquivos de texto, documentos PDF e documentos Word. Estes dados são consultados e exibidos através de um portal web interno. • Produção de notícias A RTL, uma emissora alemã, usa MaxiMedia Mpower [Max08] para produção da redação de um jornal. Mpower usa o Tamino para integrar reportagens a partir de uma variedade de fornecedores de notícias usando um subconjunto de NewsML [Cou08]. O sistema atualmente armazena mais de 300.000 artigos, abrangendo muitos gigabytes de dados. Similarmente, o TEXTML Server da IXIASOFT é usado para integrar dados de múltiplos fornecedores de notícias, cada um com seu próprio formato, em um único sistema de produção de notícias. • Dados financeiros O Commerzbank usa o Tamino [AG07] para integrar dados sobre negócios financeiros a partir de 18 sistemas diferentes. Os dados são primeiramente convertidos para XML e então armazenados no Tamino. Estes são então transformados para um esquema comum para avaliação automática e prestação de contas por diversos sistemas de departamentos administrativos. • Informações de vôos.

(24) 2.1 SGBD XML NATIVOS. 13. O sistema central de informações do aeroporto de Schiphol em Amsterdã usa o Tamino [AG07] para integrar dados de mais de 38 sistemas em tempo real. Os dados descrevem vôos (horários e portões de chegadas e partidas, tipos de aeronaves, esteiras de bagagem, entre outros) e são utilizados por mais de 50 grupos envolvidos na organização dos vôos, desde a manipulação das bagagens até a exibição das informações ao público. Os dados são armazenados em XML, usando um esquema derivado do ebXML [OAS06]. • Cuidados com a saúde O TigerLogic XML Life Sciences Data Server [Dat08b] da empresa Raining Data (baseado no TigerLogic XDMS [Dat08a]) pode integrar registros médicos e de tratamentos de saúde a partir de mais de 20 fontes de dados. Quando se trata de saúde, é comum existir a integração de dados, visto que neste domínio de problema existem muitos dados que residem em sistemas legados. • Manufatura Um sistema de controle de produção usa o SQL/XML-IMDB [Inc07] da QuiLogic para integrar dados de diferentes máquinas e sensores. Estes dados são consultados através de uma interface de Web Services, que são publicados em formatos diferentes. Os dados recuperados do Web Service são então convertidos para documentos XML com um esquema comum e armazenados na base XML nativa. • Dados instrumentais A Renault usa o X-Hive/DB [Cor07] para integrar dados de sensores em seus carros de corrida de Formula 1. Estes dados contêm informações sobre as condições do tempo e da pista, além de sinais de áudio e de vídeo. Estes dados são então disponibilizados para os mecânicos, engenheiros e projetistas, através de um portal web, para que possam ser utilizados na realização de análises condicionais. • Orientações a clientes.

(25) 2.2 ORIENTAÇÃO A MODELOS. 14. A TIBCO usa o XMS [Xpr07] da Xpriori para integrar informações de orientações a clientes. Tais informações estão disponíveis a partir de planilhas eletrônicas e vários outros documentos que devem ser transformados para um esquema comum. O sistema é usado para coordenar as orientações ao consumidor por todo o mundo.. 2.2. Orientação a modelos. O uso de modelos na construção de software tem se tornando cada vez mais comum. Este fato está ocorrendo devido à grande quantidade de benefícios que ele traz aos seus utilizadores. Nesta seção serão apresentados conceitos, padrões e tecnologias relacionadas a modelos.. 2.2.1. DSM - Modelagem específica de domínio. Modelagem específica de domínio (DSM) é uma metodologia da engenharia de software para projetar e desenvolver sistemas, mais frequentemente sistemas de tecnologia da informação. Esta metodologia envolve o uso sistemático de linguagens específicas de domínio gráficas (DSL) para representar as várias faces do sistema. Linguagens de modelagem específica de domínio tendem a dar suporte a abstrações de mais alto nível do que linguagens de modelagem de propósito geral. Assim, aquelas requerem menor esforço e menos detalhes de baixo nível para especificar um determinado sistema. Geralmente, a DSM também inclui a idéia de geração de código, automatizando a criação de códigos fonte executáveis diretamente dos modelos DSM. Estar livre da criação e manutenção manual de código fonte significa que a DSM pode melhorar significativamente a produtividade do desenvolvedor. A confiança da geração automática comparada à manual reduzirá também o número de defeitos nos programas resultantes, melhorando assim a qualidade. A DSM difere de outras tentativas anteriores de geração de código em ferramentas CASE dos anos 80, ou ainda, ferramentas baseadas em UML dos anos 90. Em ambos os casos,.

(26) 2.2 ORIENTAÇÃO A MODELOS. 15. os geradores de código e linguagens de modelagem foram construídos pelos fornecedores de ferramentas. Apesar de ser possível para um fornecedor de ferramentas criar uma linguagem DSM e seus geradores, é mais comum, quando se trata de DSM, que isto ocorra dentro de uma organização. Um ou alguns desenvolvedores experientes criam a linguagem de modelagem e os seus geradores, e o resto dos desenvolvedores a utilizam. Ter a linguagem de modelagem e o gerador construído pela organização que irá usá-los permite uma maior adequação com o domínio e suas necessidades. Também há uma redução no tempo necessário para os desenvolvedores aprenderem a linguagem de modelagem, visto que se pode utilizar termos e conceitos familiares. Finalmente, é mais fácil para a linguagem de modelagem evoluir em resposta a mudanças no domínio, dado o fato de que os requisitos de apenas uma organização precisam ser levados em consideração.. 2.2.2. Metamodelagem. Um metamodelo é uma definição precisa das construções e regras necessárias para criar modelos semânticos. Metamodelagem é uma atividade relativamente próxima à modelagem, tal como a modelagem orientada a objetos. Esta atividade produz modelos que tentam descrever o mundo observado, entretanto, com um propósito específico. O metamodelo de uma linguagem é o modelo que descreve toda a análise, projeto e desenvolvimento da estrutura conceitual de diversos diagramas que a compõem. Diversos trabalhos têm sido feitos utilizando metamodelagem com o propósito de obter mecanismos para verificar a consistência de diferentes diagramas que são gerados durante a análise do sistema. Isto é possível através do mapeamento da sintaxe e da semântica destes modelos para o metamodelo. Assim, uma verificação de consistência pode ser realizada e o metamodelo identifica distorções, omissões e generalizações comuns, baseado na gramática transformacional [Met02]..

(27) 2.2 ORIENTAÇÃO A MODELOS. 2.2.3. 16. MOF - Meta Object Facility. O Meta Object Facility (MOF) [OMG08c], padronizado pela Object Management Group (OMG) [OMG08a], define uma linguagem abstrata baseada na orientação a objetos e um framework para especificação, construção e gerenciamento dos metamodelos, independentemente da tecnologia de implementação. O modelo MOF tem uma sintaxe abstrata definida pelo próprio modelo MOF e utiliza o diagrama de classes de UML para sua sintaxe concreta. Para isto, MOF e UML têm um núcleo comum alinhado. Qualquer instância do modelo MOF pode ser representada usando um diagrama de classes UML. Novos padrões de metadados podem ser adicionados ao framework, devido a sua extensibilidade. Para que isto seja possível, sua arquitetura foi definida usando 4 camadas, as quais, são chamadas de M0, M1, M2, e M3. A Quadro 2.2 apresenta a arquitetura em camadas do MOF. Quadro 2.2: Arquitetura em camadas do MOF. Nível MOF Termos usados Exemplo M3 Meta-metamodelo Modelo MOF M2 Metamodelo, Meta-metadado Metamodelo UML M1 Modelos Modelos UML M0 Dados, Objetos Dados. Cada camada é sempre modelada por uma camada imediatamente superior. Assim, a camada M0 (onde estão os dados) é modelada por modelos UML que podem ser diagramas de classes presentes na camada M1. A camada M1 utiliza os construtores, atributos, relacionamentos da camada M2, entre outras construções. A camada M2, por sua vez, é uma instância do metamodelo MOF, que também é chamado de meta-metamodelo (M3). MOF também tem um conjunto de regras para implementar repositórios, os quais lidam com os metadados descritos pelos metamodelos. Estas regras definem um mapeamento padrão entre os metamodelos MOF e um conjunto de API (Application Programming Interface) para.

(28) 2.2 ORIENTAÇÃO A MODELOS. 17. gerenciar metadados que são instâncias destes metamodelos.. 2.2.4. MDA - Arquitetura dirigida a modelos. O Model Driven Achitecture (MDA) [OMG08b] é um padrão para desenvolvimento de sistemas que fornece maneiras de separar a modelagem do software de seus detalhes de implementação. O padrão MDA utiliza as tecnologias UML [Gro08c], MOF [OMG08c] e XMI [OMG07] como chave para seu desenvolvimento, entretanto, não está necessariamente limitado a elas. O ciclo de vida de desenvolvimento do MDA não é muito diferente do ciclo de vida tradicional e pode ser visto na Figura 2.1. As mesmas fases são identificadas, entretanto, existem algumas diferenças das quais uma das maiores está nos artefatos que são gerados durante o processo de desenvolvimento. Tais artefatos são modelos formais, isto é, modelos que podem ser entendidos por computadores. Os quatro modelos seguintes são a base do MDA [KWB03]: • Computational Independent Model (CIM) O primeiro modelo que o MDA define é o modelo de negócios que descreve um determinado negócio ou empresa. As linguagens utilizadas para a modelagem de negócios contêm um vocabulário que permite a especificação de processos de negócio, stakeholders, departamentos, dependências entre processos, entre outros. Devido ao fato de que o modelo de negócios geralmente não diz nada a respeito de sistemas de software, este também é chamado de Computational Independent Model. Sempre deve haver um modelo de software específico quando um sistema de software apoiar uma parte do negócio de uma determinada empresa. Este modelo de software é a descrição do sistema de software. Embora negócios e sistemas de software descrevam categorias completamente diferentes de sistemas no mundo real, os requisitos do sistema de software são derivados de parte do modelo de negócios que o software precisa apoiar. Para a maioria dos modelos de.

(29) 2.2 ORIENTAÇÃO A MODELOS. 18. negócio existem muitos sistemas de software com diferentes modelos de software. • Platform Independent Model (PIM) O segundo modelo que o MDA define é o modelo com o maior nível de abstração que é independente de qualquer tecnologia de implementação. Este modelo é chamado de Platform Independent Model (PIM). Um PIM descreve um sistema de software que se preocupa apenas com o domínio de problema e suas respectivas regras de negócio. Em um PIM, o sistema é modelado do ponto de vista do negócio e de como ele pode ter melhor suporte. Para o PIM não existe nenhuma influência se um sistema será implementado em um mainframe com um banco de dados relacional ou em um servidor de aplicação de EJB (Enterprise Java Beans) [Mic08e]. • Platform Specific Model (PSM) O terceiro modelo definido pelo MDA é o modelo menos abstrato e que especifica o sistema em termos de tecnologias de implementação. Este modelo é chamado de Platform Specific Model (PSM). Por exemplo, um PSM EJB é um modelo de um sistema em termos de estruturas EJB. Este EJB PSM contém termos específicos de EJB como home interface, entity bean, session bean, entre outros. Um PSM de base de dados relacional inclui termos como: tabela, coluna, chave estrangeira, entre outros. Assim, fica claro que um PSM apenas fará sentido para um desenvolvedor que tem conhecimento sobre a plataforma específica sendo utilizada no modelo. Um PSM, ou ainda, um conjunto destes é gerado a partir de um PIM. • Código O código do sistema é gerado a partir dos PSM. Devido ao fato do PSM estar bastante alinhado à tecnologia sendo utilizada, esta transformação é relativamente direta. O MDA define o CIM, PIM, PSM e código e também define como estes se relacionam entre si. Um CIM é um modelo independente de software utilizado para descrever um sistema de.

(30) 2.2 ORIENTAÇÃO A MODELOS. 19. negócios. Algumas partes de um CIM podem ser apoiadas por um sistema de software, mas o CIM permanece independente de software. A derivação automática de um ou mais PIM a partir de um CIM não é possível porque a escolha de quais partes de um CIM serão apoiados por um sistema de software é sempre realizada por um ser humano. Um PIM deve ser construído para cada sistema apoiando uma parte de um CIM. A partir de um CIM, um ou mais PIM devem ser criados, então transformados em um ou mais PSM, que são então transformados em código. O passo mais complexo no processo de desenvolvimento MDA é aquele no qual o PIM é transformado em um ou mais PSM. Além de conceitos importantes como Computational Independent Model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM) e código, o MDA introduz outros conceitos fundamentais, tais como: linguagem de transformação, regras de transformação e motores de transformação. O mapeamento entre o PIM e o PSM é realizado por um motor de transformação que usa as regras de transformação descritas na linguagem de transformação. Através dos conceitos apresentados, nota-se que o MDA propõe uma abordagem de desenvolvimento orientado a modelos, onde os esforços de desenvolvimento devem focar nos modelos do software sendo construído, e não em seu código.. 2.2.5. XMI - XML Metadata Interchange. O XMI [OMG07] é um padrão da OMG para permitir a troca de metadados através de XML. Este padrão pode ser utilizado para qualquer metadado cujo metamodelo possa ser expresso em MOF. A maneira mais comum em que se utiliza XMI é como formato para a troca de modelos UML entre ferramentas de modelagem, embora também possa ser utilizada como formato de troca para modelos de outras linguagens. [Cov02]. O padrão XMI define como as tags de XML devem ser utilizadas para representar metamodelos MOF. Assim, cada metamodelo MOF é transformado numa DTD e as instâncias dos metamodelos, ou seja, os modelos, são transformados em documentos XML validados pelas.

(31) 2.2 ORIENTAÇÃO A MODELOS. 20. Figura 2.1: Ciclo de vida do MDA. DTD. A especificação do padrão XMI consiste de: • Um conjunto de regras para produzir DTD a partir de metamodelos MOF; • Um conjunto de regras para produzir documentos XML a partir das instâncias dos metamodelos; • Princípios para o projeto de documentos XMI; e • Definição das DTD para os metamodelos MOF e UML. O padrão XMI facilita a interoperabilidade entre as ferramentas por prover um formato de intercâmbio flexível e de fácil processamento, permitindo que qualquer parser capaz de processar documentos XML, possa processar documentos XMI..

(32) 2.2 ORIENTAÇÃO A MODELOS. 21. A estrutura de um documento XMI é dividida em duas partes. A primeira parte é um cabeçalho que é representada pelo elemento XMI.Header e armazena informações sobre o conteúdo do documento, informações estas que podem conter, por exemplo, o nome e a versão da ferramenta utilizada na geração do documento. O cabeçalho possui ainda a informação sobre qual modelo, metamodelo ou metametamodelo pertencem os metadados do documento. A segunda parte é composta dos metadados e é representada pelo elemento XMI.Content. A Figura 2.2 e a Figura 2.3 apresentam, respectivamente, um exemplo de cabeçalho e um exemplo de conteúdo de um documento XMI.. <? xml v e r s i o n = " 1 . 0 " e n c o d i n g = " ISO−8859−1 " ? > < !−− < !DOCTYPE XMI SYSTEM ’ Model1311 . DTD ’ > −−> <XMI xmi . v e r s i o n = " 1 . 1 " x m l n s : M o d e l = " omg . o r g / mof . Model / 1 . 3 " t i m e s t a m p = " Sun J u l 21 19 : 0 7 : 3 4 2002 " > <XMI . h e a d e r > <XMI . d o c u m e n t a t i o n > <XMI . e x p o r t e r > U n i s y s . JCR . 1 < / XMI . e x p o r t e r > <XMI . e x p o r t e r V e r s i o n > 1 . 3 . 2 < / XMI . e x p o r t e r V e r s i o n > < / XMI . d o c u m e n t a t i o n > <XMI . metamodel xmi . name= " o r g . omg . mof . Model " xmi . v e r s i o n = " 1 . 3 " / > < / XMI . h e a d e r > <XMI . c o n t e n t >< / XMI . c o n t e n t > < / XMI>. Figura 2.2: Cabeçalho de um documento XMI O padrão XMI traz muitos benefícios para o intercâmbio e transporte de metadados e metamodelos MOF. Devido ao fato do padrão XMI ser representado em XML, este pode utilizar a infra-estrutura web, permitindo assim a publicação de metadados na internet e facilitando o trabalho de desenvolvedores que atuam em ambientes remotos..

(33) 2.3 CONSIDERAÇÕES FINAIS. 22. <XMI . c o n t e n t > < M o d e l : P a c k a g e xmi . i d = " a 3 w 2 r 6 g 4 s 3 i 8 j " name= " R e l a c i o n a l " a n n o t a t i o n =" " isRoot =" f a l s e " i s L e a f =" f a l s e " i s A b s t r a c t =" f a l s e " v i s i b i l i t y =" p u b l i c _ v i s "> < Model:Namespace . c o n t e n t s > < M o d e l : C l a s s xmi . i d = " 4 h 5 y 1 i 5 j 2 l 9 s h " name= " T a b e l a " a n n o t a t i o n =" " isRoot =" f a l s e " i s L e a f =" f a l s e " i s A b s t r a c t =" f a l s e " v i s i b i l i t y =" p u b l i c _ v i s " i s S i n g l e t o n =" f a l s e "> < M o d e l : A t t r i b u t e xmi . i d = " a 6 g 2 c 4 b 9 j 7 f 4 d " name= " nome " a n n o t a t i o n =" " scope=" i n s t a n c e _ l e v e l " v i s i b i l i t y =" p u b l i c _ v i s " i s C h a n g e a b l e = " t r u e " i s D e r i v e d = " f a l s e " t y p e = "G. 2 " > <Model:StructuralFeature . multiplicity > < M o d e l : M u l t i p l i c i t y T y p e lower="1" upper="1" i s _ o r d e r e d =" f a l s e " i s _ u n i q u e =" f a l s e " / > </ Model:StructuralFeature . multiplicity > </ Model:Attribute> < / Model:Class> < / Model:Namespace . c o n t e n t s > < / Model:Package> < / XMI . c o n t e n t >. Figura 2.3: Conteúdo de um documento XMI. 2.3. Considerações Finais. Este capítulo apresentou os conceitos básicos necessários para o entendimento deste trabalho. O capítulo foi dividido em duas partes principais, SGBD XML nativos e orientação a modelos. A parte relacionada aos SGBD XML nativos apresentou um breve discussão sobre o porquê da existência deste tipo de SGBD e apresentou algumas das ferramentas disponíveis atualmente, mostrando funcionalidades e explicando o porquê da escolhida para ser utilizada neste trabalho. Para finalizar a primeira parte, foram mostrados diversos casos de uso de SGBD XML nativo em grandes empresas multinacionais. A segunda parte do capítulo apresentou os conceitos relacionados a modelagem, apresentando conceitos como modelagem específica de domínio, metamodelagem, MOF, MDA e XMI. Apesar de aparentemente os conceitos discutidos nas duas parte do capítulo não terem muito a ver entre si, eles de fato foram utilizados em parceria para auxiliar na proposta de uma so-.

(34) 2.3 CONSIDERAÇÕES FINAIS. 23. lução para a problemática que este trabalho tenta resolver. No capítulo 4, que apresenta a implementação da solução proposta, será mostrado como estas tecnologias foram utilizadas em conjunto..

(35) C APÍTULO 3 Trabalhos relacionados. Neste capítulo são apresentados os trabalhos relacionados, além de apontar deficiências comuns ente eles. O capítulo se inicia com um breve histórico do surgimento de linguagens gráficas de consultas. Posteriormente, destaca os trabalhos relacionados, e por fim, apresenta uma análise das deficiências comuns entre os trabalhos relacionados mais relevantes.. 24.

(36) 3.1 INTRODUÇÃO. 3.1. 25. Introdução. O interesse pela criação e uso de linguagens gráficas de consultas já existe há muito tempo. No ano de 1987 Cruz et al. [CMW87] apresentaram a linguagem G, que foi a primeira proposta de linguagem de consulta gráfica orientada a objetos. Pouco tempo depois, no ano de 1988, Cruz et. al. [CMW88] apresentaram a linguagem sucessora G+. A partir desta linguagem, foram propostas as linguagens Graphlog [CM90] e Good [PdBA+ 92]. A linguagem Good oferece uma notação uniforme para bancos de dados de objetos, onde os nós representam os objetos e as pontes representam os relacionamentos. Alguns anos depois, surgiu uma linguagem que tinha uma notação parecida com a linguagem Good, linguagem esta chamada de G-Log [PPT95]. A G-Log é uma linguagem gráfica baseada em lógica que torna possível a representação e a consulta de objetos complexos por meio de grafos rotulados direcionados. Em 1998, começaram a surgir as linguagens que tinham interesse em dados semi-estruturados. A primeira a surgir com este intuito foi a WG-Log [CDPT98]. Esta linguagem foi construída para consultar páginas da internet e dados semi-estruturados adicionando a G-Log algumas funcionalidades de hipermídia. Depois de mais alguns anos, surgiu a XML-GL [CDF01, Com01], a primeira linguagem descendente da WG-Log. A XML-GL foi a primeira linguagem de consulta visual para XML, entretanto, foi projetada bem antes da XQuery [W3C08h]. A partir deste histórico é possível identificar a importância das linguagens gráficas de consulta. Neste capítulo, serão apresentadas as ferramentas que utilizam linguagens gráficas de consulta baseadas no uso de XQuery e suas principais funcionalidades. Além disto, as ferramentas serão avaliadas através de alguns critérios importantes que motivaram o desenvolvimento deste trabalho. Por fim, serão apontadas as principais limitações destas ferramentas, além de um quadro resumo das características dos trabalhos relacionados. Antes de apresentar de fato as abordagens relacionadas é importante frisar quais foram os critérios utilizados para a avaliação das ferramentas relacionadas. Tais critérios foram: • O nível de conhecimento requerido do usuário em XQuery e tecnologias relacionadas a.

(37) 3.2 XQBE. 26. XML; • Se a ferramenta requer aprendizado de uma linguagem visual por parte dos usuários; • Se houve a realização de validação com usuários leigos em XQuery e tecnologias relacionadas a XML; • Se a ferramenta foi projetada para funcionar na web; e • Se a ferramenta realiza consultas em um SGBD XML nativo.. 3.2. XQBE. Braga et. al. [BCC05] propuseram a XQBE (XQuery By Example). Esta foi a primeira linguagem de consulta gráfica a permitir que usuários não conhecedores de linguagens complexas de consulta acessassem e modificassem fontes de dados XML. A XQBE é baseada no paradigma QBE (Query By Example) [Zlo77], pois este paradigma demonstrou que uma linguagem visual é efetiva quando se trata de dar suporte a expressões de consulta intuitivas. A efetividade é ainda maior quando as construções básicas, o paradigma de consulta envolvido, e a abstração visual são compatíveis com a linguagem e o modelo de dados da camada inferior. Consequentemente, enquanto a QBE é a linguagem de consulta relacional, baseada no uso de tabelas, a XQBE é baseada no uso de árvores, assim aderindo ao modelo de dados hierárquico do XML. A ferramenta XQBE foi projetada com o objetivo principal de prover facilidade de uso. Além disso, houve também uma preocupação em tentar fazê-la o mais expressiva possível tornando-a diretamente mapeável para a XQuery, de modo que suporte qualquer interface gráfica capaz de executar no topo de qualquer implementação existente da XQuery. É claro que tais metas não podem ser completamente alcançadas ao mesmo tempo. Visto que a usabilidade é um dos fatores mais críticos para o sucesso, este fator de qualidade foi levado em consideração durante todo o processo de projeto da linguagem e da implementação da interface gráfica..

(38) 3.2 XQBE. 27. Apesar disso, sabe-se que uma representação visual para uma transformação complexa tende inerentemente a se tornar ilegível, dado o alto grau de crescimento no número de nós. A XQBE funciona melhor com transformações simples, sendo fortemente desencorajado pelos autores o seu uso para transformações muito complexas. Em relação a sua implementação, a XQBE tem uma arquitetura cliente-servidor. De um modo geral, a arquitetura da XQBE funciona da seguinte maneira: o cliente fornece o editor visual de consultas para o usuário; o servidor opera a transformação e, se requisitado, executa a consulta invocando um mecanismo de execução de XQuery. O cliente e o servidor se comunicam trocando uma representação interna das consultas em um formato intermediário, que é basicamente uma descrição dos grafos XQBE em XML. A interface gráfica da ferramenta pode ser vista na Figura 3.1.. Figura 3.1: Interface gráfica da ferramenta XQBE Apesar da motivação de Braga et. al. em criar uma ferramenta amigável, o uso de diversos elementos similares para a representação de diferentes conceitos e a necessidade de um básico.

(39) 3.3 GXQL. 28. conhecimento em XQuery prejudicaram a XQBE em atingir completamente sua meta original.. 3.3. GXQL. Z. Qin et. al. [QYLM04] criaram a ferramenta GXQL (Graphical XQuery Language) para endereçar as necessidades não atingidas pela XQBE. A ferramenta proposta é mais expressiva que a XQBE, de modo que algumas consultas que são difíceis de expressar na XQBE, são fáceis de expressar na GXQL. Além do mais, algumas consultas que podem ser representadas na GXQL, não o podem na XQBE. Diferente da anterior, a GXQL tem uma abordagem baseada em janelas gráficas, junto com suas respectivas bordas e cores como uma tentativa para melhorar a usabilidade para pessoas que não são familiares com a linguagem XQuery. A ferramenta utiliza janelas aninhadas para representar os relacionamentos entre pai e filhos. Além disto, os elementos filhos e os atributos são diferenciados visualmente. O uso de janelas aninhadas permite também a visualização da hierarquia da consulta que está sendo construída. A ferramenta apresenta, ainda, funcionalidades que auxiliam o usuário na construção das consultas, de forma que o usuário não tenha que fornecer todas as entradas textualmente, ou ainda, necessite criar todas as consultas do início. A Figura 3.2 apresenta a interface gráfica da ferramenta. Embora os autores deste trabalho tenham almejado uma maior usabilidade e intuitivismo relativo à abordagem da XQBE, a ferramenta falhou nos seguintes aspectos: a necessidade de conhecer todos os significados das bordas dos retângulos para a construção da consulta; o fato de que os usuários frequentemente perdem a visão geral da construção gráfica da XQuery devido às novas telas que são abertas durante o processo de criação da consulta XQuery; e a necessidade de barras de rolagem relativas à grande quantidade de informação gráfica mostrada. Por fim, apesar de os autores afirmarem que a ferramenta gráfica proposta é amigável para os usuários finais, esta não foi sujeita a nenhum tipo de validação com usuários. Assim, não é possível confirmar que a ferramenta de fato auxilia os usuários sem experiência na construção.

(40) 3.4 BBQ. 29. Figura 3.2: Interface gráfica da ferramenta GXQL. de consultas XQuery.. 3.4. BBQ. Munroe et. al. [MP00] apresentaram a ferramenta BBQ (Blended Browsing and Querying) que é baseada na estrutura de navegação de diretórios do sistema operacional Windows [Mic08c], o qual permite operações de drill-down para facilitar a navegação. A BBQ é a parte cliente do projeto MIX (Mediation of Information using XML) [BLP+ 98]..

(41) 3.4 BBQ. 30. Esta ferramenta facilita a consulta e navegação intuitiva de uma ou mais fontes de dados XML, o refinamento de consultas iterativamente, e ainda, a descoberta de estruturas. As fontes de dados são apresentadas em um formato de interface multi-documentos, onde cada fonte é associada a uma janela contendo seus respectivos dados e esquema mostrados lado a lado no quadro. Tanto os dados quanto o esquema são apresentados em uma estrutura de árvore, como se fossem diretórios, nos quais os usuários podem navegar e colocar condições. A interface gráfica da ferramenta pode ser vista na Figura 3.3.. Figura 3.3: Interface gráfica da ferramenta BBQ Para a realização das consultas, a ferramenta BBQ utiliza uma mistura de dois paradigmas de pesquisa: o de bancos de dados relacionais e o da web. Quando o foco é o paradigma.

(42) 3.5 XQUERYVIZ. 31. utilizado pelos bancos de dados relacionais, as consultas na BBQ são dirigidas a esquema e utilizam DTD [W3C08c]. Já quando o foco da pesquisa está voltado ao paradigma utilizado na web, assume-se que o usuário não tem certeza absoluta dos resultados esperados da consulta. Assim, o sistema enfatiza a navegação de esquemas e dados e os resultados da consulta podem ser refinados iterativamente. O refinamento iterativo de consultas é possível, porque os resultados de uma consulta podem ser utilizados como fontes em consultas subsequentes. Os usuários podem construir um documento de resultado da consulta e este documento se torna uma fonte de dados de primeira classe dentro da BBQ, significando que este pode ser navegado, consultado, ou ainda, utilizado para construir outro documento de resultado da consulta. A ferramenta BBQ dá suporte a mais do que uma fonte de dados simultaneamente e usa uma DTD adicionada ao mecanismo de inferência que ajuda a refinar o processo de escrita de consultas XQuery. Embora esta seja uma das primeiras ferramentas a focar na interação com o usuário, bem como em prover uma construção de consultas XQuery de forma mais rápida e efetiva, a ferramenta tem como público-alvo usuários que já conhecem a estrutura aninhada dos dados XML, além de alguns conceitos de linguagens de consulta a bancos de dados, tais como, junções e agregações. Assim, Munroe et. al. sugerem webmasters, desenvolvedores ou administradores de bancos de dados como usuários para a sua ferramenta.. 3.5. XQueryViz. Karam et. al. apresentaram a ferramenta XQueryViz [KBOK06]. A ferramenta tem, além de outras metas, o propósito de auxiliar os usuários finais com a criação de consultas XQuery / XPath [W3C08f]. Isto torna-se possível através da manipulação direta da representação em árvore do XML Schema usado em sua abordagem gráfica. Com o intuito de ajudar aos usuários, a ferramenta gráfica é baseada no uso de ícones e de conexões entre estes ícones. Estas conexões são criadas utilizando enlaces de dados. Além do.

(43) 3.5 XQUERYVIZ. 32. mais, devido à existência destes enlaces de dados, o usuário consegue visualizar como os dados estão sendo passados nas construções visuais. A ferramenta proposta é uma representação gráfica completa de todas as construções da XQuery, visto que os autores almejaram contemplar em sua ferramenta o maior número possível de construções desta linguagem. Apesar de ser principalmente intencionada para auxiliar estudantes da linguagem XQuery, a ferramenta XQueryViz é tão complexa quanto a linguagem XQuery em si. A Figura 3.4 apresenta a tela da ferramenta.. Figura 3.4: Interface gráfica da ferramenta XQueryViz Apesar de haver uma afirmação por parte dos autores de que a ferramenta auxilia os usuá-.

(44) 3.6 XGI. 33. rios finais que não detêm conhecimento em XQuery / XPath, esta afirmação não pôde ser confirmada, pois não foram realizados testes com usuários deste nível. Todos os usuários que participaram da avaliação da ferramenta detinham algum nível de conhecimento em XQuery / XPath. Assim, embora a ferramenta proposta seja, atualmente, a ferramenta que tem maior representatividade da linguagem XQuery, não é plausível pensar que tal ferramenta ajude usuários não conhecedores de XQuery a consultar informações em um banco de dados XML, visto que, a ferramenta requer um mínimo conhecimento de uma linguagem tão complexa quanto a XQuery.. 3.6. XGI. Li et. al., com a ferramenta XGI [LGB07], fornecem a proposta mais próxima de permitir a criação de consultas XQuery por usuários não-especialistas através de uma ferramenta intuitiva. A ferramenta aborda a construção de consultas de uma forma intermediária entre os dados estruturados e não-estruturados. Com o intuito de auxiliar os usuários no entendimento do esquema existente, a ferramenta XGI fornece aos usuários uma árvore fonte navegável. Além disto, a ferramenta fornece também uma maneira gráfica de escolher elementos que estão nesta árvore fonte para permitir que sejam adicionados ao esquema da consulta. Em se tratando de implementação, a ferramenta XGI foi projetada para funcionar em uma arquitetura WEB. Isto ocorreu devido ao fato de que o custo de implantação seria reduzido, dado que os pesquisadores bio-médicos não teriam a responsabilidade de instalar e manter o software. Além do mais, este tipo de arquitetura facilita o acesso à ferramenta, permitindo que qualquer pesquisador possa construir suas consultas de qualquer lugar em que se encontre. A Figura 3.5 apresenta a interface gráfica da ferramenta. Embora a intenção da ferramenta proposta fosse permitir que usuários não especialistas.

(45) 3.6 XGI. 34. Figura 3.5: Interface gráfica da ferramenta XGI. em XQuery pudessem criar consultas facilmente, tal objetivo não foi completamente atingido. Isto deve-se ao fato de que existem alguns conceitos utilizados na construção de consultas na ferramenta que obrigam o usuário a ter, no mínimo, algum conhecimento em XML. Como exemplo destes conceitos, pode-se citar: a necessidade de criação de um root para que o usuário possa iniciar a criação da consulta e o conhecimento dos conceitos de árvore utilizados no XML (nós filhos) para que seja criada a estrutura de retorno desta mesma consulta. Apesar de ter havido validação por parte de usuários, tal validação foi realizada apenas por um usuário especialista. Com esta validação, os autores não são capazes de demonstrar que de.

(46) 3.7 CONSIDERAÇÕES FINAIS. 35. fato a ferramenta ajuda os não-conhecedores das tecnologias relacionadas a XML na criação de consultas. Além do mais, há um reconhecimento pelos próprios criadores que a proposta de facilitar a criação de consultas pela popularização da XQuery não foi completamente alcançada, porque a ferramenta XGI apenas adiciona valor a usuários experientes em linguagens complexas como a XQuery.. 3.7. Considerações Finais. Embora as diversas ferramentas supracitadas, e suas respectivas linguagens visuais, assegurem que facilitam a recuperação de informações por usuários não-conhecedores de XQuery através do uso de interfaces amigáveis, nenhuma delas realizou testes de validação com usuários detentores deste nível de conhecimento, o que não comprova suas afirmações. Além do mais, através da análise realizada, não foi possível identificar em nenhuma destas ferramentas qual é exatamente a metodologia utilizada para gerar consultas XQuery a partir das ferramentas visuais. A XQBE e a XGI mencionam a utilização de uma BNF [Gar08], mas não explicitam como funciona o processo de transformação. Também deve ser realçado o fato de que nenhuma das ferramentas discutidas permite consultas a sistemas de gerenciamento de bancos de dados XML nativos. Assim, não permitem que os usuários usufruam das funcionalidades comumente presentes nos SGBD, tais como: controle de concorrência, segurança, recuperação de falhas, entre outros. Finalmente, é importante notar que apenas uma das ferramentas relacionadas foi desenvolvida para funcionar em um ambiente WEB, o que significa uma perda potencial significativa de cooperação e colaboração entre os usuários da maioria destas ferramentas. O Quadro 3.1 mostra um resumo das características examinadas e o resultado da análise realizada..

(47) 3.7 CONSIDERAÇÕES FINAIS. Quadro 3.1: Resumo das características avaliadas dos trabalhos relacionados.. Nível de conhecimento Ferramenta requerido do usuário XQBE Básico BBQ Básico GXQL Nenhum XQueryViz Avançado XGI Básico. Consulta Requer aprendizado Validação com Funciona SGBD de linguagem visual usuários leigos na web XML em XQuery nativo Sim Não realizado Não Não Não Não realizado Não Não Sim Não realizado Não Não Sim Não realizado Não Não Não Não realizado Sim Não. 36.

(48) C APÍTULO 4 ViXQueL. Este capítulo tem por objetivo apresentar a concepção do protótipo da solução proposta, destacando a arquitetura definida, além de sua implementação e funcionalidades.. 37.