LUCAS ROBERTO BECHERT SCHMITZ. Gerador de Relatórios Personalizados Para a Visualização do Resultado de Consultas SQL na Web

Transcrição

1 LUCAS ROBERTO BECHERT SCHMITZ Gerador de Relatórios Personalizados Para a Visualização do Resultado de Consultas SQL na Web Palmas 2004

2 2 LUCAS ROBERTO BECHERT SCHMITZ Gerador de Relatórios Personalizados Para a Visualização do Resultado de Consultas SQL na Web Monografia apresentada como requisito da disciplina de Prática de Sistemas de Informação II (TCC) do curso de Sistemas de Informação, sob a orientação do Prof. Jackson Gomes de Souza Palmas 2004

3 3 LUCAS ROBERTO BECHERT SCHMITZ Gerador de Relatórios Personalizados Para a Visualização do Resultado de Consultas SQL na Web Monografia apresentada como requisito da disciplina de Prática de Sistemas de Informação II (TCC) do curso de Sistemas de Informação, sob a orientação do Prof. Jackson Gomes de Souza Aprovado em dezembro de 2004 BANCA EXAMINADORA Prof. Jackson Gomes de Souza Centro Universitário Luterano de Palmas Prof. Eduardo Leal Centro Universitário Luterano de Palmas Profª. Parcilene Fernandes de Brito Centro Universitário Luterano de Palmas Palmas 2004

4 4 De que valem leis, onde falta nos homens o sentimento da justiça? (Obras Completas de Rui Barbosa, v. 16, t. 5, p. 225.)

5 5 AGRADECIMENTOS Bem, chego ao final de mais uma etapa de minha vida, creio que estando mais fortalecido e mais preparado para as próximas etapas. Sendo assim, gostaria de compartilhar este momento agradecendo aos que, de uma forma ou outra, contribuíram comigo nesta caminhada. Inicialmente agradeço a Deus, nosso senhor, que tudo nos fornece. Seu amor por nós concede a mim e a todas demais pessoas com quem convivo uma grande dádiva. Agradeço à minha família, que mesmo não podendo estar junto a mim em todos os momentos desses últimos 4 (quatro) anos de minha vida, sempre me deram força para acreditar em meus sonhos e condições para completar essa caminhada. Meu pai (Elton Valdir Schmitz), minha mãe (Verônica Bechert Schmitz) e meu irmão (Felipe Eduardo Bechert Schmitz), saibam que amo muito vocês! Agradeço muito ao meu orientador, o professor Jackson (Jack), que sabiamente me orientou no decorer deste e de outros trabalhos, indicando sempre o melhor caminho para encontrar as respostas necessárias, isso quando já não tinha as respostas. Jack, sem suas contribuições não teria conseguido terminar esse trabalho, obrigado. Agradeço aos professores que, através de suas aulas e de atendimentos extra-classe, me passaram parte de seu conhecimento: Ademildo, Aline, Andrés, Augusto, Cristina, Deise, Eduardo Leal, Eduardo Piveta, Fabiano, Fernando, Flávio, Jackson (olha ele de novo), João Nunes, Madianita, Madson, Mário Sérgio, Parcilene, Ricardo e Thereza. Agradeço aos grandes amigos que conheci nesta instituição, formando uma equipe da pesada: André (Rincon), Carlos Eduardo (Careli), Edeilson (Ed), Jorge (Trial), Leandro (Maciel). Nossa amizade se tornou muito forte e verdadeira nestes anos, tanto nas farras quanto nos momentos mais difíceis de se lidar. Agradeço muito a vocês, nossa amizade é eterna. Em especial, claro, existem alguns professores que gostaria de citar novamente, são eles: Fabiano Fagundes: papai do Careli e do Rincon, mas posso dizer que ele também foi um pai pra mim, mesmo não tendo sido meu orientador nos períodos finais do curso, mas me orientou muito em várias outras ocasiões. Esse cara nunca mediu esforços para nos mostrar o caminho certo, apesar de que algumas vezes ainda

6 6 tenhamos ido pelo errado, mas somos humanos né... Diria que ele foi o principal responsável por formar o nosso grupo de amigos dentro da faculdade e pela grande maioria das coisas que fizemos e aprendemos neste período; Jackson Gomes: mais um papai, além de professor, orientador e patrão, sempre foi muito amigo, tanto nos momentos de exigir nossos serviços, no Portal, quanto nos momentos de descontração. Sempre nos ensinou a nos manter calmos e a confiar e temer a Deus acima de tudo. Parcilene Fernandes: a mamãe do Ed, uma mulher forte e batalhadora. Durante a faculdade, como coordenadora e professora, sempre cuidou do nosso curso com os punhos, conseguindo melhores condições para trabalharmos (ela foi minha patroa ), estudarmos e aprender sempre mais; foi nossa professora no primeiro e último período da faculdade, assumindo algumas das matérias tidas por muitos como as mais complicadas do curso e mesmo assim soube muito bem nos passar o conhecimento e até mesmo nos ensinar a aprender. Thereza Patrícia: a TPPP, a mamãe do Maciel também não mediu esforços para nos ajudar. Seu humor sempre contagiou o ambiente do Linc. Posso dizer que, juntamente com o Fabiano e a Parcilene, ela é a responsável pelo que é hoje o curso de Sistemas de Informação do CEULP/ULBRA; Agradeço também aos demais amigos, colegas de sala de aula e demais conhecidos; não citarei nomes para não correr o risco de cometer injustiças ao esquecer de alguém. Agradeço também a você leitor que neste momento me prestigia lendo este trabalho. A ordem dos nomes citados acima não indica preferência, afinal, isto nem mesmo eu sei responder. Os nomes contidos nos parágrafos estão em ordem alfabética.

7 7 SUMÁRIO LISTA DE FIGURAS...8 LISTA DE TABELAS...10 LISTA DE ABREVIATURAS INTRODUÇÃO REVISÃO DE LITERATURA GERADOR GRÁFICO DE CONSULTAS SQL Geração e Execução da Consulta SQL JAVASCRIPT ASP.NET ASP.NET Master Pages XML SCHEMA Datatypes XML E ASP.NET TRABALHOS CORRELACIONADOS Crystal Reports Microsoft Access MATERIAL E MÉTODOS LOCAL E PERÍODO MATERIAL METODOLOGIA RESULTADOS E DISCUSSÃO MODELAGEM DO SISTEMA Arquitetura Geral do Sistema Arquitetura do Sistema de Geração do Relatório EDITOR HTML WYSIWYG - PINEDIT RELAÇÃO COM O TRABALHO DE ESTÁGIO DEFINIÇÃO DA ESTRUTURA PARA REPRESENTAÇÃO DO MODELO DE RELATÓRIOS INTERFACE PARA EDIÇÃO DO MODELO DE RELATÓRIO APRESENTAÇÃO DO RELATÓRIO RESULTANTE CONSIDERAÇÕES FINAIS TRABALHOS FUTUROS...66 APÊNDICE 1 GERARCONSULTA.ASPX.VB...69 APÊNDICE 2 GERARRELATORIO.ASPX.CS...74

8 8 LISTA DE FIGURAS Figura 1: Interface gráfica do sistema Figura 2: Interface gráfica do sistema Figura 3: Modelo de compilação ASP. Fonte AÉCE (2004)...20 Figura 4: Modelo de compilação ASP.NET, semelhante ao Java. Fonte AÉCE (2004). 20 Figura 5: Arquivo MasterPage.master...23 Figura 6: Arquivo Default.aspx...24 Figura 7: Página Resultante execução do arquivo Default.aspx Figura 8: Exemplo de preâmbulo para um documento XML Schema...26 Figura 9: Exemplo de definições em um documento XML Schema...27 Figura 10: Exemplo de definições em um documento XML Schema...30 Figura 11: Utilização da classe XMLTextWriter...32 Figura 12: Documento XML gerado...33 Figura 13: Utilização da classe XMLTextReader...34 Figura 14: Relatório gerado no Crystal Reports (BOSA, 2004) Figura 15: Interface para montagem de relatórios no Microsoft Access...38 Figura 16: Exemplo de relatório gerado no Microsoft Access...39 Figura 17: Modelo de classes do sistema de geração de relatórios...43 Figura 18: Modelo de classes do sistema de geração de relatórios...44 Figura 19: Modelo de classes do sistema de geração de relatórios...45 Figura 20: Registrando as dll s do PinEdit Figura 21: Adicionando o PinEdit ao conjunto de ferramentas do Microsoft Visual Studio. 47 Figura 22: Utilizando o PinEdit na aplicação...48 Figura 23: Selecionando as opções da barra de ferramentas do PinEdit...49 Figura 24: Trabalho anterior montagem da consulta SQL Figura 25: Trabalho atual Construção do relatório a partir da consulta SQL Figura 26: Estrutura definida em XML Schema para armazenamento do relatório...53 Figura 27: Exemplo de documento XML gerado a partir da estrutura definida pela Figura anterior Figura 28: Áreas da interface para a edição do relatório....56

9 9 Figura 29: Arquivo master com a estruturação do conteúdo da ppágina de edição do relatório. 58 Figura 30: Montagem do relatório graficamente Figura 31: Montagem do relatório em linguagem HTML...60 Figura 32: Relatório exibido ao usuário Figura 33: Parte do código de substituição de valores para a construção do relatório a ser visualizado pelo usuário....62

10 10 LISTA DE TABELAS Tabela 1: Exemplos de Tags utilizadas no desenvolvimento de um XML Schema (O REILLY, 2004)...28 Tabela 2: Alguns tipos de dados primitivos em XML Schema (ANDERSON, 2001)...29 Tabela 3: Alguns tipos de dados gerados a partir dos tipos primitivos do XML Schema (ANDERSON, 2001) Tabela 4: Exemplos de classes da Namespace System.XML (MSDN-XML, 2004) Tabela 5: Cronograma de atividades para o desenvolvimento do trabalho...42

11 11 LISTA DE ABREVIATURAS ASP = Active Server Pages ASP.NET = Active Server Pages.NET CLR = Common Language Runtime DHTML = Dynamic HTMLHTML = Hyper Text Markup Language IIS = Internet Information Service MSIL = MicroSoft Intermediate Language SGBDs = Sistemas Gerenciadores de Bancos de Dados SQL = Structured Query Language W3C = World Wide Web Consortium XML = extensible Markup Language

12 12 RESUMO Neste trabalho é proposto o desenvolvimento de um aplicativo Web para a estruturação e apresentação de relatórios a partir de consultas SQL. Este trabalho é a continuidade de um trabalho anterior, onde o usuário pode montar a consulta SQL a partir de uma interface gráfica na Web. Sendo gerada essa consulta, o usuário poderá escolher a forma de visualização dos dados retornados por ela. Isso se faz necessário no sentido de oferecer a esse usuário um conjunto de opções que possibilite uma maior interação com o sistema e um maior grau de entendimento do relatório gerado, pois ele é quem irá montálo. Algumas das opções que serão disponibilizadas ao usuário na montagem do relatório são: posicionamento de conteúdo, cor, adição de imagens, formatação de tabelas e junção de mais de um campo da consulta em uma mesma coluna de resultados. Palavras-chaves: plataforma.net, personalização, Relatórios na Web.

13 13 ABSTRACT In this work is proposed the development of a web application for structure and presentation of reports based on SQL queries. This work is the continuity of a previous one, in which the user is allowed to create an SQL query through a visual interface on the web. This query being generated, the user can choose the form of visualization of the returned data. This is necessary for to offer this user a set of options that makes possible an enhanced interaction with the system and a higher level understanding of the generated report, for he will build it. Some of the options that will be available to the user when creating the report are: content positioning, color, addition of images, table formatting and junction of more than one field of the query in an unique column of results. Keywords:.NET plataform, personalization, Web Reports.

14 14 1 INTRODUÇÃO Este trabalho tem como foco a continuação do trabalho realizado no período de Estágio Supervisionado (disciplina Prática de Sistemas de Informação I, cursada no primeiro semestre de 2004), no qual foi desenvolvida uma aplicação que permitia a geração, a partir de elementos gráficos, de consultas SQL via Web, através do Browser (navegador web). Após o desenvolvimento da ferramenta citada, detectou-se que a visualização dos dados retornados pelas consultas da forma tradicional (no formato de uma tabela) não apresenta o nível de funcionalidade visual requerido pelo usuário, como agrupamentos de dados e exibição de imagens. Assim, é necessário desenvolver uma forma de apresentação dos dados ao nível de relatórios. Portanto, o sistema anterior foi estendido, possibilitando a criação destes relatórios. Uma alternativa para que se possam atender as necessidades do usuário, é dar a ele a liberdade de escolher o que e como quer visualizar o resultado de uma consulta SQL. Para isso foi desenvolvida neste trabalho uma ferramenta gráfica para formatação de relatórios a serem exibidos na Web a partir de uma consulta a um banco de dados. Os relatórios possuem as suas características próprias, como: divisão de seções (cabeçalho, rodapé, detalhes), campos calculados e apresentação de imagens; e estas características foram devidamente implementadas para que a funcionalidade de personalização fosse apresentada ao usuário. Uma característica destes relatórios personalizados, é que somente a parte de apresentação é modificada. A partir dessa modificação feita pelo usuário na forma de visualizar o relatório, o sistema obtém uma

15 15 característica de interface adaptável, ou seja, o próprio usuário adapta a interface ao que quer visualizar. O texto desse relatório está dividido da seguinte maneira: A seção 2 traz uma breve revisão de literatura a respeito das tecnologias utilizadas no decorrer do trabalho. Essa seção traz uma descrição sobre o trabalho desenvolvido no período de Estágio supervisionado e também características de tecnologias como: JavaScript, ASP.NET e XML Schema. O XML Schema foi utilizado neste trabalho para a definição da estrutura dos documentos XML que serão responsáveis por armazenar os relatórios gerados pelo usuário do sistema. Sendo assim, para a utilização desses documentos XML, teve de ser feito um estudo sobre uma das formas disponíveis em ASP.NET para se trabalhar com esses documentos. Esses estudos também serão apresentados na seção 2 do presente trabalho. Para finalizar esta seção, são apresentadas ao leitor algumas características do Crystal Reports, que é uma ferramenta já existente para edição de relatórios. A seção 3 traz os materiais e métodos utilizados; A seção 4 contém os Resultados alcançados com o desenvolvimento do trabalho, como: o modelo de classes, a interface do sistema e os componentes utlizados. No texto desta seção foi feita uma relação com as tecnologias descritas na seção de revisão. A seção 5 traz as considerações finais a respeito do trabalho. Por fim a seção 6 mostra alguns possíveis trabalhos futuros para expandir o funcionamento da ferramenta aqui desenvolvida.

16 16 2 REVISÃO DE LITERATURA Como parte integrante deste trabalho, foi realizada uma revisão bibliográfica sobre os recursos a serem utilizados no decorrer do desenvolvimento do mesmo. Entre estes está um dos disponibilizados na versão 2.0 da plataforma.net, o Master Pages e as classes disponíveis nesta plataforma para lidar com documentos XML. Outros recursos utilizados foram o XML Schema e a linguagem de Programação JavaScript. Uma seção de trabalhos correlacionados também foi acrescentada na revisão, faldiscorrendo sobre o Crystal Reports e o Microsoft Access, que são ferramentas utilizadas para geração de relatórios. Nesta etapa de revisão, inicialmente será feita uma breve explanação do trabalho desenvolvido anteriormente, ou seja, o gerador gráfico de consultas SQL. O conteúdo da revisão bibliográfica não será especificamente uma descrição completa ou uma documentação total dos itens envolvidos no desenvolvimento do sistema, mas será uma referência objetiva, de modo a apresentar ao leitor as definições de cada tecnologia utilizada no decorrer do trabalho. As próximas subseções trarão essas definições. 2.1 Gerador gráfico de consultas SQL. Como este trabalho é continuação de um anterior, se faz necessária uma breve explanação do trabalho anteriormente desenvolvido. Para a criação da interface gráfica foram utilizados Web Controls ASP.NET, objetos da DynAPI e a DHTML, com a utilização de elementos HTML e códigos JavaScript. O resultado final da interface do sistema pode ser visualizado na Figura 1.

17 Figura 1: Interface gráfica do sistema. Como pode ser observado na Figura 1, a interface do sistema está dividida em quatro partes (painéis): 1 Área para adição das layers (tabelas selecionadas pelo usuário); 2 Área com as tabelas existentes na base de dados e com as tabelas pelo usuário adicionadas à consulta; 3 Área com os campos já adicionados à consulta; 4 Área com a consulta em modo texto; Geração e Execução da Consulta SQL A geração da consulta SQL, através da interface gráfica, é feita a cada modificação feita pelo usuário. Sempre que o usuário adiciona uma tabela (Painel 2), seleciona algum campo das tabelas (Painel 1), ou acrescenta algum critério (Painel 3), a consulta é modificada

18 18 (Painel 4). Para cada campo selecionado, é criada uma linha no Painel 3 da interface gráfica (Figura 1) para que o usuário possa adicionar um critério ou uma forma de ordenação. Para montar a consulta é feita uma estrutura de repetição entre as linhas que foram criadas (cada campo selecionado das tabelas que o usuário escolheu para a consulta). Através desta, são montadas as cláusulas SELECT, WHERE e ORDER BY. Para montar a cláusula FROM, é feita outra repetição, que percorre todas as layers adicionadas à interface gráfica, percorrendo assim as tabelas adicionadas à consulta. O resultado da consulta é mostrado ao usuário abaixo dos painéis da interface gráfica em forma de uma tabela, com os respectivos campos escolhidos pelo usuário e as respectivas linhas retornadas pela consulta à base de dados, conforme observado na Figura 2, a seguir. Figura 2: Interface gráfica do sistema. Como pôde ser observado na Figura 2, o resultado é retornado ao usuário em forma de uma tabela, relacionando os campos da consulta através de colunas. 2.2 JavaScript (FEATHER, 1997) afirma que em um esforço da Netscape para expandir as funcionalidades de seu browser, esta desenvolveu uma linguagem de programação que pode ser embutida nas páginas Web. Essa linguagem logo foi batizada como JavaScript,

19 19 aproveitando a popularidade da linguagem de programação Java, da Sun Microsystems. JavaScript possui uma sintaxe muito próxima a C e C++. Para FEATHER (1997) JavaScript é uma linguagem dirigida por eventos e estes são definidos pelas ações que podem ocorrer em uma página Web, como por exemplo, um botão que é clicado, o mouse sendo arrastado ou até mesmo um documento que tenha sido carregado no Browser. Sendo assim, sempre que algum evento ocorre na página, um código JavaScript pode ser acionado. JavaScript é uma linguagem de script utilizada para tornar as páginas mais interativas com o usuário. Algumas das características de JavaScript são definidas por W3SCHOOLS-JS (2004): Projetado para adicionar interatividade a páginas HTML É usualmente embutida no código HTML; É uma linguagem interpretada; Suportada pela maiora dos browsers; Pode alterar o código HTML dinamicamente; Orientada a eventos; 2.3 ASP.NET De acordo com PAYNE (2001), o ASP.NET apresenta um novo modelo de programação e uma grande variedade de ferramentas que o diferencia do ASP clássico. Para MSDN (2004), é parte da plataforma.net Framework e permite que se faça uso das características que esta oferece. MSDN (2004) afirma ainda que a plataforma.net é um componente Windows completo para o apoio à construção e à execução de aplicações. O.NET proporciona um ambiente de desenvolvimento com muitos recursos para os desenvolvedores. Pode-se dizer que o.net disponibiliza um ambiente de desenvolvimento que possui, entre outras características: ser multi-plataforma, ser multi-linguagem, trabalhar com o paradigma de programação orientado a objetos, ter uma interoperabilidade entre as linguagens de programação e possuir uma vasta biblioteca de classes (MSDN, 2004). Analisando as informações supracitadas, pode-se afirmar que a.net possui um modelo de desenvolvimento muito parecido com o modelo do Java, onde, na compilação

20 20 do código-fonte do programa, um novo código, em uma outra linguagem, é gerado para que possa ser entendido em ambientes diferentes. As classes desenvolvidas em.net podem ser acessadas por diversos dispositivos (Desktops, dispositivos móveis, etc). As Figuras 3 e 4 a seguir apresentam a diferença, citada anteriormente, existente entre as formas de programação do ASP.NET e do ASP clássico. Figura 3: Modelo de compilação ASP. Fonte AÉCE (2004). Figura 4: Modelo de compilação ASP.NET, semelhante ao Java. Fonte AÉCE (2004). Conforme pode ser observado na análise as Figuras 3 e 4, existe muita diferença entre os modelos de compilação de um código ASP e de um ASP.NET. Na tecnologia ASP o código é sempre interpretado antes do envio ao cliente, ou seja, a cada acesso a página é novamente interpretada. Enquanto que, através do modelo de compilação proposto pelo ASP.NET, as páginas primeiramente são compiladas gerando o código MSIL, depois esse código é interpretado pela CLR. Após essas etapas o cliente recebe a página solicitada. A princípio esse processo pode parecer mais demorado que o do ASP, mas vale ressaltar que uma vez feito esse processo, ele só se repete quando o arquivo original sofre alguma

21 21 alteração. A modificação veio para possibilitar que aplicações desenvolvidas com a.net Framework pudessem ser executadas em qualquer sistema operacional, desde que este forneça suporte à plataforma. Dando continuidade aos estudos da plataforma.net, a próxima subseção tratará de algumas das novidades trazidas com a versão 2.0 do.net Framework ASP.NET 2.0 Até o momento, a mais nova versão da plataforma de desenvolvimento.net. Para HOMER (2003), ASP.NET 2.0, também chamada de Whidbey, dirige-se tanto a grupos de desenvolvimento, quanto a usuários que buscam um aperfeiçoamento. Os principais objetivos dessa nova versão da plataforma de desenvolvimento podem ser observados na listagem abaixo (HOMER, 2003): Redução no número de linhas de código: com um modelo de programação que livra o desenvolvedor de escrever resmas de código; Aumento da produtividade do desenvolvedor: está relacionado à diminuição do código, porém, também é influenciado pelo fato de que a plataforma oferece várias soluções para o desenvolvimento Web; Desenvolvimento para todos os dispositivos em um único local: fornece uma arquitetura de desenvolvimento que possibilita a construção de aplicações para diversos dispositivos, Desktop, Web, Dispostivos Móveis, etc; Plataforma de acesso rápido a servidores Web, com características que melhoram o desempenho da aplicação; Fornece um fácil gerenciamento da aplicação: trazendo uma ferramenta gráfica, integrada ao IIS, para configuração; e, Ser de fácil implementação, unindo as características supracitadas. Uma das novidades da versão 2.0 da plataforma.net é o conceito de Master Pages, que será melhor explanado na próxima subseção.

22 Master Pages Uma característica introduzida na versão 2.0 do ASP.NET possibilita que o desenvolvedor defina um layout para aplicação Web e aplique múltiplos conteúdos a cada uma das diferentes páginas com base nesse mesmo layout. As Master Pages fornecem um método fácil para criação de páginas consistentes e com uma interface de qualidade (MSDN-MP, 2004). A definição para Master Pages consiste em definir uma página mestre (daí o termo) para que outras páginas possam se basear em sua estrutura. Na maioria das aplicações Web existem elementos-padrão, assim como: logotipos, menus de navegação e mensagens de copyright. Uma única Master Page pode estabelecer todos esses elementos. Se toda a aplicação for baseada nesta Master Page previamente definida, então todas as páginas incluirão automaticamente esses elementos-padrão (MSDN-MP, 2004). Ou seja, em um único arquivo Master Page, pode ser definida a estrutura das páginas de toda a aplicação. Uma Master Page pode conter Web controls, User controls, conteúdo HTML e scripts, como em uma página ASP.NET normal. Existem três importantes diferenças entre um Master Page e uma página ASP.NET normal, são elas (MSDN-MP, 2004): A extensão do arquivo de uma Master Page é.master ; Master Pages devem possuir a diretiva <% Master %> ao invés de <% Page %>, existente nas páginas ASP.NET normais; Uma Master Page pode conter 0 (zero) ou mais controles ContentPlaceHolder, que são os controles usados para marcar as áreas passíveis de adição de conteúdo, ou seja, são usados para definir o layout da página mestre; A partir dessas informações nota-se que, para utilizar o conceito de Master Pages em uma aplicação, são necessários no mínimo dois arquivos, um.aspx e um.master. As Figuras a seguir (4, 5 e 6) mostram um exemplo da utilização desses arquivos e a imagem do resultado da execução dos mesmos. A Figura 5 traz um exemplo de arquivo Master Page. A estrutura da página de exemplo utiliza duas seções principais: esquerda ( Left ) e central ( Center ). A partir desta definição todas as páginas criadas para o site precisarão definir conteúdo apenas para as seções referidas; não sendo

23 23 necessário criar conteúdo para outras seções da página porque as mesmas já estão constantes, definidas na página mestre (Master page). 1: Master Language="C#" %> 2: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " 3: <html xmlns=" > 4: <head runat="server"> 5: <title>tcc - Lucas Roberto Bechert Schmitz</title> 6: </head> 7: <body> 8: <form id="form1" runat="server"> 9: <div style="background-color:gray; border:0; cursor:hand; width:200px; height:300px; position:absolute; left: 10px; top: 10px;"> 10: <asp:contentplaceholder id="left" runat="server"> 11: </asp:contentplaceholder> 12: </div> 13: <div style="background-color:deepskyblue; border:0; cursor:hand; width:500px; height:300px; position:absolute; left: 220px; top: 10px;"> 14: <asp:contentplaceholder id="center" runat="server"> 15: </asp:contentplaceholder> 16: </div> 17: </form> 18: </body> 19: </html> Figura 5: Arquivo MasterPage.master. Conforme pode ser observado na Figura 5, toda a estrutura da página pode ser colocada no arquivo master. Na linha 1 é feito o uso da diretiva <% Master %>. Entre as linhas 2 e 19, o documento HTML é formado. Na linha 9 é criada uma div que conterá o primeiro controle ContentPlaceHolder (linha 10) utilizado na página. Nessa div, são definidas questões de posicionamento para o conteúdo do controle. O controle definido, possui um atributo denominado ID contendo o valor Left ; esse ID vai ser utilizado para a identificação do layout a ser utilizado na página ASP.NET. Da mesma forma ocorre nas linhas 13 e 14, onde são definidos, respectivamente, uma nova div e um novo controle, agora com o valor Center para o ID. Tendo sido definido o arquivo master, pode ser definido também o arquivo ASP.NET (.aspx ) que irá se basear na estrutura definida. A Figura 6 demonstra um exemplo de arquivo ASP.NET.

24 24 1: Page MasterPageFile="~/MasterPage.master" ClassName="_default" CompileWith="~/Default.aspx.cs" %> 2: <asp:content ID="Parte1" ContentPlaceHolderID="Left" Runat="Server"> 3: <br><b><font color="#ffffff">parte 1 - Operations</b></font> 4: </asp:content> 5: <asp:content ID="Parte2" ContentPlaceHolderID="Center" Runat="Server"> 6: <br><b>parte 2 - Center</b> 7: </asp:content> Figura 6: Arquivo Default.aspx. Na Figura 6 observa-se a formação do arquivo ASP.NET. A linha 1 traz a diretiva <% Page %>, que é normal em arquivos ASP.NET e nesta diretiva foi inserido o atributo MasterPageFile. Este atributo servirá para indicar em qual Master Page o documento será baseado; no caso, o arquivo MasterPage.master definido na Figura 4. Entre as linhas 2 e 4 é definido o conteúdo do ContentPlaceHolder de ID igual a Left, definido no arquivo.master. Para isso, na linha 2, foi utilizado o controle Content com o atributo ContentPlaceHolderID, que recebe o valor Left, fazendo aligação do conteúdo ao layout. A linha 3 traz o conteúdo a ser colocado no controle Content e a linha 4 finaliza o controle. O conteúdo pode ser qualquer elemento HTML, texto ou Web Controls. Da mesma maneira ocorre com as linhas de 5 a 7, porém nelas está definido o conteúdo para o controle ContentPlaceHolder de ID equivalente a Center. Após a definição desses dois arquivos, pode ser visualizada a página resultante na Figura 7, logo a seguir.

25 25 Figura 7: Página Resultante execução do arquivo Default.aspx. De acordo com a Figura 7, percebe-se que os conteúdos Parte 1 - Left e Parte 2 - Center, definidos no arquivo Default.aspx, ficaram dispostos de acordo com o posicionamento definido no arquivo MasterPage.master. 2.4 XML Schema W3C-1 (2004) afirma que o XML Schema é uma estrutura utilizada para definir o universo de um documento XML e de seus componentes. Provê um inventário das marcações XML construídas para representar o esquema e define o esquema a ser seguido para a construção do documento XML. Os schemas são autodocumentáveis, assim, em XML Schema, as estruturas podem ser usadas para definir, descrever e ainda catalogar vocabulários de documentos XML (W3C-1, 2004). Desta forma, XML Schema é uma alternativa para a definição da estrutura de um documento XML. W3C-1 (2004) diz também que as finalidades de um XML Schema são: definir e descrever um documento XML; construir e documentar o documento proposto.

26 26 Um XML Schema é constituído por (W3C-1, 2004): tipos de dados; elementos; e, atributos. ANDERSON (2001) diz que as informações disponíveis em um documento XML Schema estão dispostas na forma de elementos e atributos, como em um documento XML. A formação de um XML Schema consiste de um preâmbulo e de zero ou mais definições ou declarações. O preâmbulo é encontrado dentro do elemento raiz do documento, o elemento <schema>. Este deve possuir pelo menos um de três atributos básicos, são eles: 1: targetns: URI do esquema que está sendo utilizado; 2: version: especifica a versão do esquema; 3: xmlns: espaço reservado para identificar a especificação do XML Schema a ser utilizada; Um exemplo de preâmbulo em um documento XML Schema pode ser visualizado na Figura 8 logo abaixo. 1: <?xml version= 1.0?> 2: <schema 3: targetns= 4: version= 1.0 5: xmlns= 6: > 7:... 8: </schema> Figura 8: Exemplo de preâmbulo para um documento XML Schema. Conforme observado na Figura 8, o preâmbulo do documento XML Schema apresentado constitui-se de atributos do elemento schema. Entre as linhas 3 e 5 define-se que: o esquema criado tem o nome lucas.xsd e está situado em está em sua versão 1.0; e referencia a especificação situada em

27 27 O resto do documento seria formado pelas definições dos elementos e atributos a serem utilizados no esquema, assim como também os tipos de dados. A próxima subseção tratará especificamente sobre os tipos de dados suportados em um XML Schema. Os elementos e atributos de um XML Schema podem ser definidos de acordo com o exemplo da Figura 9. 1: <? xml version= 1.0?> 2: <schema...> 3: <element name="pessoa"> 4: <complextype> 5: <sequence> 6: <element name="nome" type="string"/> 7: <element name="idade" type="integer"/> 8: </sequence> 9: <attribute name="sexo" use="required" type="string"/> 10: </complextype> 11: </element> 12: </schema> Figura 9: Exemplo de definições em um documento XML Schema. Conforme pode ser visto na Figura 9, o documento é formado com a seguinte estrutura: na linha 2 é definido o preâmbulo; entre as linhas 3 e 11, a tag element define um elemento denominado pessoa; esse elemento é formado por dois outros elementos e por um atributo; as linhas 6 e 7 definem respectivamente os novos elementos: nome do tipo string e idade do tipo integer; na linha 9 é definido um atributo chamado sexo do tipo string. Para que o elemento pudesse ser formado por outros elementos ou atributos, teve de ser definido que ele seria de um tipo complexo (linhas 4-10). Entre as linhas 5 e 8 definese que os elementos nome e idade deverão aparecer em seqüência no documento XML através da tag sequence. O REILLY (2004) define que a tag sequence, em um XML Schema, serve para definir um grupo ordenado de elementos, onde todos são necessários. Pode-se entender sua utilização comparando-o com o operador lógico AND, ou seja, os dois elementos definidos na tag sequence necessariamente existirão para cada tag elemento definida no documento XML. Uma outra possibilidade à tag sequence é a utilização da tag choice, que é definida por O REILLY (2004) como sendo utilizada para formar um grupo mutuamente exclusivo. Sendo assim entende-se que nem todos os

28 28 elementos contidos na tag choice deverão necessariamente aparecer, igualmente ao se utilizar o operador lógico OR. Para se formar um XML Schema, várias outras tags podem ser utilizadas. A Tabela 1 demonstra algumas dessas tags explicando como as mesmas podem ser utilizadas. 7DEHOD([HPSORVGH7DJVXWLOL]DGDVQRGHVHQYROYLPHQWRGHXP;0/6FKHPD 2 5(,//< Tag all annotation appinfo Utilização Descreve um grupo qualquer de elementos. Define uma informação sobre o dado, para ser identificada por um usuário ou por um agente. Informação para ser identificada pela aplicação. documentation Documentação do arquivo. enumeration fractiondigits Key keyref include length Observarção restrita ao tipo do dado. Usada para limitar a quantidade de valores definidos. Observação utilizada para definir o número de dígitos fracionários de um tipo numérico. Definição de uma chave. Definição de uma referência a uma chave já existente no documento. Representa inclusão de algum XML Schema já existente na Namespace do arquivo. Define o tamanho de um valor. maxexclusive Define um valor máximo (exclusivo). minexclusive Define um valor mínimo (exclusivo). maxinclusive Define um valor máximo (inclusivo). mininclusive Define um valor mínimo (inclusivo). union Define uma união entre diferentes tipos de dados. A próxima subseção tratará exclusivamente sobre a definição dos tipos de dados, datatypes, em XML Schema Datatypes

29 29 Para ANDERSON (2001), os Datatypes dizem respeito à especificação do espaço de valores suportados pelo XML Schema. O XML Schema fornece um conjunto de tipos dados primitivos e um mecanismo para gerar novos tipos de dados, derivados dos primitivos. Em XML Schema, a partir de tipos de dados pré-existentes, o usuário pode criar novos tipos de dados, conforme tenha necessidade. Isso é vantajoso no sentido de facilitar a elaboração de documentos XML Schema que atendem realmente as necessidades da aplicação a ser desenvolvida. A Tabela 2 a seguir traz exemplos de tipos primitivos do XML Schema. 7DEHOD$OJXQVWLSRVGHGDGRVSULPLWLYRVHP;0/6FKHPD$1'(5621 Tipo Definição String Seqüência finita de caracteres. Boolean Conjunto de valores lógicos (True, False, 1 e 0). Double Binary Uri Decimal Abranje os números pertencentes ao conjunto dos números Reais. Corresponde a um ponto flutuante de 64 bits. Armazena dados na forma binária. Referencia um URI. Conceito matemático parecido com o double, porém cobre uma gama menor de valores. Consiste em uma seqüência de dígitos separados por um ponto. Como pode ser observado na Tabela 2, o XML Schema traz alguns tipos de dados já conhecidos nas linguagens de programação utilizadas atualmente, como C# e Java. A Tabela 3 demonstra exemplos de alguns tipos de dados gerados a partir dos demonstrados na Tabela 2. 7DEHOD$OJXQVWLSRVGHGDGRVJHUDGRVDSDUWLUGRVWLSRVSULPLWLYRVGR;0/6FKHPD $1'(5621 Tipo primitivo Tipo gerado Especificação String language Identificadores de linguagem natural. String ENTITIES Entidades XML 1.0. String IDREFS Tipo de atributo XML 1.0.

30 30 Decimal Integer Apenas números inteiros Integer Integer Integer positive Números inteiros positivos. non-negative Números inteiros não-negativos e zero. integer Conforme pode ser visualizado na Tabela 3, a partir de tipos de dados primitivos do XML Schema, pode-se gerar outros tipos de dados específicos. Ainda desses novos tipos de dados gerados, outros podem ser criados, como é o caso do integer que foi gerado a partir do decimal e serviu como base para outros dois novos tipos. Como por exemplo, com base no tipo integer, que abranje todos os números inteiros (negativos, positivos e o zero), puderam ser criados tipos distintos: um que abrange apenas os números inteiros positivos (integer positive) e outro que abrange os não-negativos e o zero (nonnegative integer). Para executar esse processo de derivação de tipos, é necessária a criação de um novo documento XML Schema. Nesse documento, ao invés de serem definidos elementos e atributos, serão definidos os tipos de dados. A Figura 10 demonstra como criar novos tipos de dados em XML Schema. 1:... 2: <datatype name="alfabetoparcial" source="string"> 3: <minexclusive value="a"/> 4: <maxexclusive value="m"/> 5: </datatype> 6:... Figura 10: Exemplo de definições em um documento XML Schema. De acordo com a Figura 10, foi definido um novo tipo de dado, denominado alfabetoparcial. Esse tipo tem sua base no tipo primitivo string (linha 2, atributo source). De acordo com as linhas 3 e 4, que definem os limites para os possíveis valores desse novo tipo de dado, o tipo alfabetoparcial poderá conter caracteres situados entre a (mínimo) e m (máximo).

31 XML e ASP.NET Durante a realização desse trabalho foram utilizados conceitos de XML e de ASP.NET, desta forma foi realizado um estudo sobre a relação entre essas duas tecnologias. O ASP.NET é um modelo de desenvolvimento baseado no paradigma de orientação a objetos, logo seria necessária a utilização de classes para trabalhar com um documento XML. Já existem implementações dessas classes e essas podem ser encontradas no conjunto de classes existentes na Namespace do ASP.NET denominada System.XML. A System.XML possui classes que dão suporte a vários padrões XML, entre esses padrões podem ser citados (MSND-XML, 2004): XML 1.0 incluindo suporte a DTD; XML Namespaces; XSD Schemas (XML Schema); Expressões XPath; Transformações XSLT; DOM versões 1 e 2; Exemplos de classes da Namespace System.XML e suas respectivas descrições podem ser observadas na Tabela 4 abaixo. 7DEHOD([HPSORVGHFODVVHVGD1DPHVSDFH6\VWHP;0/06'1;0/ Classe Descrição XMLDocument XMLElement XMLAttribute XMLText Representa um documento XML. Representa um Elemento. Representa um Atributo. Representa o Texto contido em um elemento. XMLTextReader Representa um leitor que provê acesso aos dados contidos no documento XML. XMLTextWriter Representa um escritor que provê formas de gerar informações XMLEntity em um documento XML, de acordo com as recomendações da W3C para XML. Representa a declaração de uma Entidade. XmlValidatingReader Verifica a validade de um documento XML de acordo com algum esquema de validação (DTD, XML Schema, etc).

32 32 Na Tabela 4 podem ser observados exemplos de classes do ASP.NET que trabalham com documentos XML. Essas classes e as demais existentes na Namespace, fornecem meios para que o usuário possa acessar todo o conteúdo do documento, assim como criar um novo documento XML em sua completude. No presente trabalho, são tratadas em especial as classes XMLTextReader e XMLTextWriter. A classe XMLTextWriter é utilizada para criar o documento XML definido pelo usuário, através do sistema, para representar a estrutura do relatório. Por sua vez, a classe XMLTextReader veio a ser utilizada para percorrer esse mesmo documento, montando assim, juntamente com a consulta SQL, o relatório a ser visualizado pelo usuário. Os detalhes sobre a utilização dessas classes no presente trabalho serão explanados na seção de Resultados e Discussão. Como exemplos da utilização dessas classes podem ser visualizados os códigos que seguem nas Figuras de 11, 12 e 13. 1:... 2: public void gerarxml(string q1, string q2) 3: { 4: XmlTextWriter writer = new XmlTextWriter("C:\\docXML.xml", null); 5: writer.writestartdocument(); 6: writer.formatting = Formatting.Indented; 7: writer.writestartelement("pessoa"); 8: writer.writestartelement("nome"); 9: writer.writestring(q1); 10: writer.writeendelement(); 11: writer.writestartelement("idade"); 12: writer.writestring(q2); 13: writer.writeendelement(); 14: writer.writeendelement(); 15: writer.writeenddocument(); 16: writer.close(); 17: 18:... Figura 11: Utilização da classe XMLTextWriter. Conforme pode ser visto na Figura 11, na utilização da classe XMLTextWriter, o documento XML vai sendo criado de acordo com uma determinada ordem na execução de seus métodos. Na linha 4, tem-se a declaração do objeto writer que cria um arquivo chamado docxml.xml no diretório C. Após a criação do arquivo, o primeiro passo é

33 33 criar o cabeçalho do documento XML através do método WriteStartDocument()(linha 5). Em seguida, na linha 6 define-se o tipo de formatação do documento utilizando a propriedade Formatting na qual definiu-se que o documento teria uma formatação identada (Formatting.Indented). As linhas de 7 a 14 são responsáveis por criar os elementos que irão compor esse documento. Note que como o XML obedece à estrutura de uma árvore de dados, para criar seus elementos, também deve ser seguir essa estrutura, como segue: Na linha 7, é iniciado o elemento Pessoa; Linhas 8 a 10: cria-se o elemento Nome com o conteúdo do parâmetro q1; o A linha 8 inicia o elemento através do método WriteStartElement(); o A linha 9 insere o conteúdo do elemento atrvés do método WriteString(); o E, a linha 10 fecha o elemento com o método WriteEndElement(); O mesmo processo ocorre com as linhas de 11 a 13, criando o elemento Idade com o conteúdo do parâmetro q2; Como o elemento Pessoa era o elemento pai dos demais, ele foi finalizado apenas na linha 14, mantendo a hierarquia do documento; A linha 15 é responsável por finalizar o documento XML, através do método WriteEndDocument(); Na linha 16, é utilizado o método Close() para fechar o objeto writer e possibilitar que o arquivo criado seja acessado por algum usuário; O exemplo apresentado na Figura 11, gera o seguinte documento XML (Figura 12): 1: <?xml version= 1.0?> 2: <Pessoa> 3: <Nome> 4: conteúdo de q1 5: </Nome> 6: <Idade> 7: conteúdo de q2 8: </Idade> 9: </Pessoa> Figura 12: Documento XML gerado.

34 34 Conforme se observa na Figura 12, o documento XML foi gerado com três elementos, sendo dois deles (Nome e Idade) filhos de um elemento principal (Pessoa). Após ter sido feita a criação do documento XML, se faz necessária a leitura das informações do mesmo. Para isso utiliza-se a classe XMLTextReader. Um exemplo da utilização dessa classe é apresentado na Figura, 13 a seguir. 1:... 2: public void lerxml() 3: { 4: XmlTextReader reader = new XmlTextReader("C:\\docXML.xml"); 5: while (reader.read()) 6: { 7: switch (reader.nodetype) 8: { 9: case XmlNodeType.XmlDeclaration: 10: Console.Write("<?xml version='1.0'?>"); 11: break; 12: case XmlNodeType.Element: 13: Console.Write("Início do Elemento: " + reader.name); 14: break; 15: case XmlNodeType.Text: 16: Console.Write("Texto: " + reader.value); 17: break; 18: case XmlNodeType.Comment: 19: Console.Write("Comentário: " + reader.value); 20: break; 21: case XmlNodeType.EndElement: 22: Console.Write("Fim do Elemento: ", reader.name); 23: break; 24: 25: 26: 27:... Figura 13: Utilização da classe XMLTextReader. Observando a Figura 13, percebe-se que na linha 4, é criado o objeto reader como instância da classe XMLTextReader; Esse objeto fará acesso ao arquivo docxml.xml, localizado no diretório C. A leitura do documento é feita através de uma estrutura de repetição que ocupa as linhas de 5 a 25 e é executada enquanto o arquivo puder ser lido através do método Read(). Nessa repetição é feito um switch que verifica o tipo do nó que está atualmente no leitor, através da propriedade NodeType.

35 35 Para se fazer os testes do switch, ou seja, os cases, são utlizados alguns dos valores possíveis para essa propriedade que são: XmlNodeType.XmlDeclaration (linha 9): contém a tag de declaração de um documento XML, por exemplo <?xml version= 1.0?>; XmlNodeType.Element (linha 12): contém um elemento qualquer do documento XML, por exemplo <pessoa>; XmlNodeType.Text (linha 15): responsável pelo conteúdo dos elementos XML; XmlNodeType.Comment (linha 18): contém partes comentadas em um documento XML, por exemplo <!--comentário-->; e, XmlNodeType.EndElement (linha 21): armazena as tags de fechamento dos elementos XML, por exemplo </pessoa>; Em cada um desses casos, são utilizados propriedades específicas para se obter o conteúdo atual do leitor (reader). Por exemplo, para o caso dos tipos Element e EndElement esse conteúdo é encontrado na propriedade Name, já nos casos Text e Comment, esse valor está na propriedade Value. 2.6 Trabalhos Correlacionados Nesta seção serão demosntrados dois exemplos de trabalhos correlacionados ao sistema aqui desenvolvido, são eles o Crystal Reports da Business Objects e o Access da Microsoft Crystal Reports Esta seção traz uma breve definição a respeito do Crystal Reports 1. Ela se faz necessária para que se possa demonstrar um exemplo de uma ferramenta já existente relacionada ao trabalho aqui desenvolvido. O Crystal Reports é uma ferramenta gráfica para auxiliar o desenvolvedor na construção de relatórios complexos que apresentam informações disponíveis em uma fonte de dados. 1 Ferramenta Proprietária utilizada na criação gráfica de relatórios a partir de consultas a bancos de dados. Mais informações: reporting/crystalreports/default.asp

36 36 Para BOSA (2004), o Crystal Reports fornece uma rápida apresentação de dados para aplicações Windows e para Web. É um conjunto de ferramentas intuitivas que ajudam a resolver o desafio associado ao formato de apresentação de dados em aplicações Web e Windows. Ainda de acordo com BOSA (2004), provê meios para acesso, formatação, e integração de dados com aplicações.net e J2EE, fornecendo maior interatividade com desenvolvedores experientes em qualquer uma dessas plataformas de desenvolvimento. Um exemplo de relatório gerado pelo Crystal Reports é visualizada na Figura 14 abaixo Figura 14: Relatório gerado no Crystal Reports (BOSA, 2004). De acordo com a Figura 14, o Crystal Reports fornece uma interface amigável e simples, porém fornece também opções para formalizar relatórios muito complexos, inclusive com a inclusão de gráficos no resultado das consultas efetuadas. Para edição e visualização dos relatórios, a interface está dividida basicamente em quatro partes: 1 As ferramentas para edição de textos, tabelas, funções, etc; 2 A apresentação das seções existentes no relatório em questão;

37 37 3 Lista dos dados resultantes da consulta na fonte de dados; 4 Responsável pela visualização gráfica do relatório; Para BOSA (2004), esse conjunto de ferramentas possui tecnologia de acesso a qualquer fonte de dados, incluindo XML, OLAP e as demais. Fornece também um controle completo com muitas opções de formatação para a apresentação dos dados ao usuário final. Em relação à plataforma.net, BOSA (2004) afirma que o Crystal Reports provê aos desenvolvedores uma integração entre velocidade e qualidade na formatação da apesentação dos dados, para que estes possam atender as exigências dos usuários finais de suas aplicações. Está disponível nos ambientes de programação Microsoft Visual Studio.NET e Borland C#Builder. Usando o Crystal Reports na plataforma.net pode-se (BOSA, 2004): Criar relatórios para aplicações Windows, Web, and XML Web Services; Gerar relatórios gráficos a partir dos dados consultados; Ganhar tempo escrevendo menos código em seu projeto; Durante as seções da Revisão de Literatura do presente trabalho, foram apresentadas as tecnologias utilizadas no desenvolvimento da aplicação proposta. Para dar continuidade ao trabalho, a próxima seção deste relatório traz uma explanação dos materiais e dos métodos utilizados durante esse desenvolvimento Microsoft Access Outra ferramenta com funcionalidades semelhantes ao do trabalho desenvolvido é o gerador de relatórios do Microsoft Access. De acordo com BRYDON (2005) o Microsoft Access é um Sistema Gerenciador de Banco de Dados (SGBD) que utiliza o modelo relacional. Em um nível mais básico, um SGBD é um programa que facilita o armazenamento e recuperação de informações do disco rígido de um computador. MICROSOFT (2005) afirma que o Microsoft Access oferece um conjunto eficiente de ferramentas sofisticadas o suficiente para desenvolvedores profissionais, além disso, são de fácil aprendizagem para novos usuários. Algumas de suas características são (MICROSOFT, 2005):

38 38 Incorpora uma ampla gama de fontes de dados; Vinculação de sistemas comerciais; Analisar e Compartilhar informações com eficiência; Criar páginas Web com informações do Banco de Dados; Para gerar um relatório no Access, deve-se inicialmente abrir um arquivo de banco de dados, seja local ou via rede (LAN). A interface de montagem do relatório no Access é exibida na Figura 15, a seguir. Figura 15: Interface para montagem de relatórios no Microsoft Access. Como pode ser observado na Figura 15, o Access divide o relatório em seções (Cabeçalho, Detalhe e Rodapé) e em cada uma dessas seções podem ser adicionados vários componentes, como: campos de uma consulta, textos, imagens, elementos de formulário, etc. Um exemplo de relatório construído através do Microsoft Access é apresentado na Figura 16, a seguir.

39 39 Figura 16: Exemplo de relatório gerado no Microsoft Access. No exemplo visualizado na Figura 16, o relatório possui as seguintes características: No cabeçalho existe o título do relatório: Lista Alfabética de Produtos. Ainda no cabeçalho foi inserida a data de geração do relatório; Na seção de detalhe existem textos representando o nome dos campos e, abaixo deles, a representação dos campos, cujos valores são encontrados no banco de dados consultado; A cada letra inicial dos produtos encontrados no banco de dados, uma linha divisáoria é apresentada no relatório; Em relação à capacidade de se gerar um relatório na Web, o Microsoft Access fornece opções para ser gerada uma página.asp, um arquivo.pdf ou.html, sendo assim, páginas estáticas. No caso do.asp, ainda é necessária a utilização de um componente ActiveX, o que dificulta na questão da portabilidade do relatório, pois somente usuários do Internet Explorer conseguiriam visualizá-lo. Qualquer modificação no relatório só pode ser feita através do próprio Microsoft Access, gerando uma nova página

40 40 estática. Um dos pré-requisitos do trabalho aqui desenvolvido é o de utilizar uma base de dados remota, via Web, e essa funcionalidade não é fornecida pelo Microsoft Access. Porém, o Access também tem muitas vantagens, algumas delas são: Facilidade para acesso a recursos locais; Uso de imagens e outras mídias para apresentação; Entre outras;

41 41 3 MATERIAL E MÉTODOS Neste capítulo, serão apresentados os detalhes referentes aos materiais e metodologia utilizados na implementação da aplicação descrita no primeiro capítulo, além dos utilizados no processo de desenvolvimento deste trabalho. 3.1 Local e Período O trabalho foi desenvolvido no Portal, um dos laboratórios do Curso de Sistemas de Informação, no Centro Universitário Luterano de Palmas. Os trabalhos tiveram início no mês de agosto de 2004 e término em dezembro de Material O material utilizado pode ser dividido em três categorias: hardware, software e fontes bibliográficas. A primeira, é constituída por um micro-computador com 2 processadores Intel Pentium III com clock de 800 MHz cada um, 655 Mb de memória RAM e 3 HD s com capacidades respectivas de 20, 20 e 40 Gb, localizado na sala do Portal. Este ficou responsável pelo armazenamento das bases de dados utilizadas, pela criação e execução da aplicação proposta neste trabalho e pela edição deste relatório. Os softwares utilizados foram os seguintes: Microsoft Word, para a redação do relatório e leitura de algumas referências bibliográficas. Microsoft SQL Server 2000, para a criação e manutenção das bases dados utilizadas.

42 42 Microsoft.NET Framework 2.0, para execução das classes desenvolvidas. Microsoft.NET Framework SDK (English) 2.0, para referência e utilização das classes providas pela plataforma.net. Microsoft Visual Studio.NET 2003, para codificação da aplicação. Adobe Acrobat Reader, para a leitura de algumas referências bibliográficas. Com relação às referências bibliográficas, estas foram encontradas na biblioteca da Instituição, em livros de professores e na Internet, principalmente. 3.3 Metodologia A implementação pode ser dividida em duas etapas: a criação do banco de dados para testes e a construção da aplicação que fará o acesso a essa base. O banco de dados foi criado em Microsoft SQL Server 2000.A linguagem de programação utilizada para a construção da aplicação foi o C#. Para o desenvolvimento do trabalho foi definido inicialmente pelo professor orientador Jackson Gomes de Souza um cronograma, visualizado na Tabela 5, a seguir. 7DEHOD&URQRJUDPDGHDWLYLGDGHVSDUDRGHVHQYROYLPHQWRGRWUDEDOKR Data inicial Tarefa 02/08 Revisão de Literatura: JavaScript. 09/08 Revisão de Literatura: Plataforma.NET /08 Revisão de Literatura: XML Schema. 30/08 Revisão de Literatura: XML e ASP.NET. 13/09 Revisão de Literatura: Crystal Reports. 20/09 Análise da estrutura de dados para o armazenamento/gerenciamento dos modelos de relatórios. 04/10 Implementação: Relação com o trabalho de estágio. 08/11 Resultados e Discussão. 22/11 Considerações 29/11 Revisão final de trabalho.

43 43 4 RESULTADOS E DISCUSSÃO Como continuidade do presente trabalho, nesta seção serão expostos os resultados obtidos a partir dos estudos realizados e da implementação do sistema proposto. Esses resultados serão demonstrados através de textos e figuras, sempre relacionados com as tecnologias descritas na seção de Revisão de Literatura. 4.1 Modelagem do Sistema Para o desenvolvimento do sistema proposto neste trabalho, foi gerado o seguinte modelo de classes (Figura 17): Figura 17: Modelo de classes do sistema de geração de relatórios. A Figura 17 traz as classes criadas para este trabalho, ou seja, as classes utilizadas no gerador de consultas e no gerador de relatórios. A classe Relatorio foi criada para

44 44 conter as informações referentes ao relatório gerado pelo usuário, assim como por criar o documento XML a partir dessas informações e o relatório a partir desse documento. Enquanto a classe Banco é responsável por executar a consulta no banco de dados. As classes Consulta e Tabela foram utilizadas para a geração da consulta SQL, juntamente com o pacote DynAPI. A classe Valida é utilizada para validação da consulta SQL, visto que o usuário pode alterar a consulta no modo texto da interface de criação da mesma Arquitetura Geral do Sistema Nesta seção será explicado o funcionamento do sistema em sua totalidade. Inicialmente deve ser ressaltado que o sistema foi desenvolvido para ser utilizado em conjunto a outros sistemas, é um sistema para ser adicionado a outro (add-on). Um exemplo seria a sua utilizão junto a um sistema de uma empresa qualquer. A Figura 18 representa essa ligação. Sistema qualquer Gerador de Relatórios BD Figura 18: Modelo de classes do sistema de geração de relatórios. Conforme se observa na Figura 18, o sistema de geração de relatórios é inserido em outro sistema Web que já possua uma base de dados. Essa base de dados será acessada pelo gerador de relatórios com o intermédio do Sistema. Toda a questão relacionada a segurança no acesso às informações do banco de dados é tratada com a utilização de logins e senhas do próprio banco de dados. O Administrador do Sistema cria logins e senhas com acesso às

45 45 informações necessárias e disponibiliza esses dados para os usuários poderem fazer suas consultas e seus relatórios via Web Arquitetura do Sistema de Geração do Relatório Esta seção foi criada para fornecer ao leitor uma visão de como funciona a parte do sistema responsável pela geração do relatório. Um modelo de funcionamento é apresentado na Figura 19, a seguir. Figura 19: Modelo de classes do sistema de geração de relatórios. Conforme se observa na Figura 19, o funcionamento do sistema ocorre da seguinte forma: 1 O usuário define a estrutura do relatório; 2 A partir dessa estrutura, o sistema gera o documento XML com todas as informações inseridas pelo usuário na interface; 3 Com os dados gravados nesse documento XML (Consulta e Seções do Relatório), o sistema executa a consulta e gera o relatório.

46 Editor HTML WYSIWYG - PinEdit Para facilitar o trabalho do usuário e manter um dos principais objetivos desta ferramenta, que é poder ser utilizada por usuários leigos, se fez necessária a utilização de componentes para edição gráfica do código HTML gerado para o relatório. O componente escolhido, o PinEdit trás várias opções de configuração, tanto para escolher as ferramentas a serem disponibilizadas, quanto para escolher a forma de visualização do usuário (gráfica ou código). A versão 3.5 do PinEdit, utilizada neste trabalho, está disponível para download no site Após instalar o componente na máquina, será criado um site local com exemplos de utilização do mesmo. Para adicionar esse componente à aplicação desenvolvida neste trabalho, foram seguidos alguns passos para realizar a configuração: 1 Copiar a pasta editor do diretório da aplicação PinEdit para o diretório da aplicação que pretende desenvolver, mantendo esse nome para a pasta; 2 Copiar a pasta toolbar do diretório da aplicação PinEdit para o diretório da aplicação que pretende desenvolver, mantendo esse nome para a pasta; 3 Referenciar as dll s que se encontram na pasta bin da aplicação PinEdit juntamente ao projeto da aplicação a ser desenvolvida, conforme apresentado na Figura 20 abaixo:

47 47 Figura 20: Registrando as dll s do PinEdit. 4 Adicionar o componente PinEdit ao conjunto de ferramentas disponíveis no editor que estiver utilizando, no caso o Microsoft Visual Studio Observe a Figura 21 abaixo: Figura 21: Adicionando o PinEdit ao conjunto de ferramentas do Microsoft Visual Studio. 5 Após as etapas anteriores, o PinEdit já está pronto para ser adicionado à aplicação, de acordo com exemplo da Figura 22:

48 48 Figura 22: Utilizando o PinEdit na aplicação. O PinEdit tem várias propriedades que podem ser modificadas de acordo com a necessidade do usuário, tais como: tamanho do editor, estilo do editor, e a barra de ferramentas. Como é um editor de conteúdo HTML, disponibiliza todas as ferramentas que podem ser encontradas em aplicativos de mesma funcionalidade, como por exemplo, o Macromedia Dreamweaver e o próprio Microsoft Visual Studio. Para o gerador de relatórios desenvolvido neste trabalho, a barra de ferramentas dos compnentes PinEdit utilizados foram configuradas para terem apenas ferramentas de edição de texto e tabelas. Um exemplo de configuração da barra de ferramentas do PinEdit é apresentado na Figura 23 abaixo.

49 49 Figura 23: Selecionando as opções da barra de ferramentas do PinEdit. Conforme pode ser observado na Figura 23, a configuração das barras de ferramentas é completamente visual, possibilitando ao desenvolvedor escolher dentro de uma lista quais ferramentas deseja utilizar. 4.3 Relação com o trabalho de Estágio Esse trabalho foi desenvolvido como sendo uma continuidade ao trabalho feito no semestre anterior, para a disciplina de Prática de Sistemas de Informação I (Estágio). No trabalho anterior, foi desenvolvida uma ferramenta em que, a partir de uma interface gráfica, o usuário monta uma consulta em linguagem SQL. Ainda no trabalho desenvolvido no estágio, após a montagem da consulta, o usuário executava a mesma e o resultado dessa execução junto ao banco de dados era retornado em forma de uma tabela com o nome dos campos divididos em colunas e os seus respectivos conteúdos nas linhas subseqüentes.

50 50 Relacionando os dois trabalhos, não haverá mais a execução da consulta logo após sua construção. Antes disso, o usuário é enviado a uma outra página do sistema. Nessa nova página, ele poderá montar também o formato em que deseja visualizar esse resultado, escolhendo quais informações deseja visualizar no cabeçalho e no rodapé, e escolhendo a disposição das informações na seção de detalhes do relatório. A seção de detalhes representa o local do relatório em que irão aparecer realmente as informações do banco de dados, ou seja, os registros selecionados pela consulta. As Figuras 24 e 25 que seguem demonstram como será a união dos dois trabalhos. Figura 24: Trabalho anterior montagem da consulta SQL. Nessa parte do sistema (Figura 24), o usuário monta a consulta SQL de acordo com a escolha das tabelas e dos campos a serem exibidos. Após montar a consulta ele pode acionar o botão Montar Relatório para ser direcionado a página seguinte, que é apresentada na Figura 25, logo abaixo.

51 51 Figura 25: Trabalho atual Construção do relatório a partir da consulta SQL. Chegando à página exibida na Figura 25, o usuário tem a possibilidade de definir a forma que deseja visualizar as informações por ele selecionadas na consulta. Após definir esse formato, o botão Gerar Relatório pode ser acionado e então o relatório será exibido de acordo com a formatação imposta anteriormente. 4.4 Definição da estrutura para representação do modelo de relatórios Para a construção do relatório, pensou-se em dividí-lo em três seções: Cabeçalho, Rodapé e Detalhes. Sendo que a seção de Detalhes está destinada a conter os campos da consulta SQL. Para dar suporte a consultas com resultados agrupados, ou seja, com a cláusula GROUP BY, a parte de Detalhes pode ser composta tanto por texto (como as demais), como por uma novo conjunto de seções (Cabeçalho, Rodapé e Detalhes). Essa

52 52 característica definida na estrutura se torna interessante a ponto de o usuário poder visualizar o resultado da consulta, dividindo-o de acordo com os campos agrupados na consulta. Porém, a ferramenta desenvolvida durante o trabalho de estágio, o gerador gráfico de consultas SQL, não oferece suporte à construção de consultas com campos agrupados. A partir disso, os relatórios também não podem ser gerados com a utilização da característica de agrupamento existente na estrutura. Foi definido que, para o armazenamento da estrutura do relatório, seria utilizada a linguagem XML. Essa escolha foi feita pelas características de serialização dos dados e pelo suporte tanto a dados estruturados, como semi-estruturados que XML fornece. Um outro fator que auxiliou na escolha dessa linguagem, foi a existência, no ASP.NET, de classes que tratam desse tipo de documento. Sendo assim, a estrutura para representar esse documento XML foi definida na linguagem XML Schema, que possibilita uma definição bem detalhada de estruturas XML. A estrutura definida na linguagem XML Schema é apresentada na Figura 26, a seguir.

53 53 1: <?xml version="1.0"?> 2: <xsd:schema xmlns:xsd=" 3: <xsd:element name="header"> 4: <xsd:complextype> 5: <xsd:sequence> 6: <xsd:element ref="text" /> 7: </xsd:sequence> 8: </xsd:complextype> 9: </xsd:element> 10: <xsd:element name="footer"> 11: <xsd:complextype> 12: <xsd:sequence> 13: <xsd:element ref="text" /> 14: </xsd:sequence> 15: </xsd:complextype> 16: </xsd:element> 17: <xsd:element name="detail"> 18: <xsd:complextype> 19: <xsd:choice> 20: <xsd:element ref="text" /> 21: <xsd:element ref="section" /> 22: </xsd:choice> 23: </xsd:complextype> 24: </xsd:element> 25: <xsd:element name="section"> 26: <xsd:complextype> 27: <xsd:sequence> 28: <xsd:element ref="header" /> 29: <xsd:element ref="detail" /> 30: <xsd:element ref="footer" /> 31: </xsd:sequence> 32: <xsd:attribute name="idsection" use="required" type="xsd:integer" /> 33: </xsd:complextype> 34: </xsd:element> 35: <xsd:element name="text" type="xsd:string" /> 36: <xsd:element name="query"> 37: <xsd:complextype> 38: <xsd:sequence> 39: <xsd:element ref="text" /> 40: </xsd:sequence> 41: </xsd:complextype> 42: </xsd:element> 43: <xsd:element name="report"> 44: <xsd:complextype> 45: <xsd:sequence> 46: <xsd:element ref="query" /> 47: <xsd:element ref="section" /> 48: </xsd:sequence> 49: </xsd:complextype> 50: </xsd:element> 51: </xsd:schema> Figura 26: Estrutura definida em XML Schema para armazenamento do relatório.

54 54 Como pode ser observado na Figura 26 acima, o documento XML Schema gerado para estruturar os relatórios abrange não só as seções do relatório, mas também a consulta SQL gerada pelo usuário. Esse elemento foi criado já pensando em uma possível extensão do trabalho. O usuário pode, por exemplo, armazenar o documento XML de seu relatório e, nas próximas vezes em que precisar gerar o mesmo relatório, não mais precisará gerar a consulta e a estrutura, mas apenas fazer o envio desse arquivo XML ao sistema e o mesmo, agora possuindo as informações necessárias, geraria o relatório. A disposição da declaração dos elementos é a seguinte: Na linha 2 está situado o preâmbulo do documento XML Schema; Entre as linhas 3 e 9 é declarado o elemento Header que contém como seu filho o elemento Text; As linhas de 10 a 16 declaram o elemento Footer que contém o elemento Text; Entre a linha 17 e a linha 24 é declarado o elemento Detail que tem como seu filho um elemento Text; Entre as linhas 25 e 34 é criado o elemento Section, que irá conter os elementos definidos anteriormente (Header, Detail, Footer); A linha 35 define o elemento Text que contém uma string; Entre as linhas 36 e 42 define-se o elemento Query, que contém como filho o elemento Text; Por fim, entre as linhas 43 e 50, é criado o elemento report que conterá todos os elementos do relatório (Query e Section); Utilizando a estrutura apresentada na Figura 26, pode ser criado o seguinte documento XML, apresentado na Figura 27 a seguir.

55 55 1: <?xml version="1.0"?> 2: <Report> 3: <Query> 4: <Text>Consulta SQL</Text> 5: </Query> 6: <Section> 7: <Header> 8: <Text>Cabeçalho</Text> 9: </Header> 10: <Detail> 11: <Text>Detalhes</Text> 12: </Detail> 13: <Footer> 14: <Text>Rodapé</Text> 15: </Footer> 16: </Section> 17: </Report> Figura 27: Exemplo de documento XML gerado a partir da estrutura definida pela Figura anterior. De acordo com o visualizado na Figura 27, foi montado um documento XML que possui como elemento Principal o Report. A partir desse elemento são criados seus filhos Query e Section. O Elemento Query possui como filho o elemento Text. Já o elemento Section, por sua vez, possui vários filhos: Header, Detail e Footer. Estes possuem como filho um elemento Text. 4.5 Interface para edição do modelo de relatório Com o ojetivo de oferecer o maior número de opções possíveis para que o usuário monte seu relatório, a interface do sistema é composta das seguintes partes: Área com os elementos a serem inseridos no relatório; Área aonde a estrutura do relatório é visualizada pelo usuário; Área para os comandos a serem executados, no caso o botão de geração do relatório; A representação dessa interface pode ser visualizada na figura 28.

56 Figura 28: Áreas da interface para a edição do relatório. Conforme visualizado na Figura 28, as partes 1, 2 e 3 da interface de geração do relatório contém respectivamente: (1) Elementos disponíveis de se adicionar ao relatório, como: o Campos selecionados na consulta; o Funções predefinidas para o sistema; o Imagens que o usuário pretende adicionar ao relatório; (2) Área de edição gráfica do relatório; (3) Área com o botão para executar o método que gera o relatório; O funcionamento dessa interface é o seguinte: após a criação da consulta pelo usuário na interface anterior, essa consulta é armazenada na seção do usuário e a página de geração do relatório é carregada.

57 57 Para a parte 1, os campos selecionados na consulta são adicionados a uma lista para que o usuário possa utilizá-los na geração do relatório. Uma outra lista é preenchida com as funções cadastradas no sistema. Também é adicionada à interface uma lista para que, nela, o usuário possa adicionar imagens de que possa necessitar em seu relatório. Para a parte 2, são inseridos na página três componentes PinEdit, que servirão para a definição dos conteúdos respectivos à cabeçalho, detalhes e rodapé. Tanto os campos, como as funções e as imagens, adicionadas a esta parte da interface, serão apenas representadores de conteúdo, pois seu conteúdo real só será apresentado após a execução do método que cria o relatório. E por fim, na parte 3, é adicionado um botão, o qual será utilizado para executar o método que irá construir o documento XML representante do relatório e o relatório propriamente dito. O código construído para carregar a lista de campos e de funções disponíveis para o usuário é demonstrado na Figura X abaixo. Essa estruturação da página em três partes foi definida através de um arquivo master (Master Pages). O código de geração desse arquivo pode ser visualizado na Figura 29.

58 58 Figura 29: Arquivo master com a estruturação do conteúdo da ppágina de edição do relatório. Como visto na Figura acima (29), a página é dividida em três contentplaceholder. Cada um será responsável por conter as seções citadas anteriormente, na seguinte relação: Na linha 10, o de id igual a Operations, é responsável pela parte 1 da interface; Na linha 14, o de id igual a Report, é responsável pela parte 2 da interface; e, 1: <%@ Master Language="C#" %> 2: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " 3: <html xmlns=" > 4: <head runat="server"> 5: <title>tcc Lucas - Geração da Estrutura do Relatório</title> 6: </head> 7: <body> 8: <form id="form1" runat="server"> 9: <div align="left" style="background-color:#dddddd; position:absolute; left: 10px; width: 240px; top: 10px; height: 620px;"> 10: <asp:contentplaceholder id="operations" runat="server"> 11: </asp:contentplaceholder> 12: </div> 13: <div align="center" style="backgroundcolor:#eeeeee; position:absolute; left: 260px; width: 700px; top: 10px; height: 560px;"> 14: <asp:contentplaceholder id="report" runat="server"> 15: </asp:contentplaceholder> 16: </div> 17: <div align="right" style="left: 260px; width: 700px; position: absolute; top: 580px; height: 50px; 18: background-color: #dddddd"> 19: <asp:contentplaceholder ID="Executions" Runat="Server"></asp:ContentPlaceHolder> 20: </div> 21: </form> 22: </body> 23: </html> Por fim, a parte 3 fica a cargo do que possui id igual a Executions ; A utilização de Master Pages nesse trabalho possibilitou a definição de um layout padrão para a interface do sistema. A partir dessa estruturação da interface, só restou a

59 59 definição de quais componentes seriam apresentados ao usuário em cada uma das partes desse layout. 4.6 Apresentação do relatório resultante Esta seção do trabalho traz uma demonstração do funcionamento real da aplicação desenvolvida. Para isto serão apresentadas algumas figuras com a etapa de construção do relatório e com a visualização do mesmo após a execução da consulta. Inicialmente é apresentada na Figura 30 a etapa de montagem do relatório. Figura 30: Montagem do relatório graficamente. Nessa etapa apresentada na Figura 30, o usuário já montou a consulta e está montando a estrutura da exibição do relatório. Ele pode escolher os campos que deseja visualizar, assim como a cor do texto, se irá ou não utilizar tabelas, figuras, entre outras coisas. Todas essas opções estão ao alcance do usuário em cada seção do relatório, pois

60 60 como pode ser percebido, existe um editor HTML para cada. Uma outra forma de construir o relatório é apresentada na Figura 31. Figura 31: Montagem do relatório em linguagem HTML. Como o Sistema também poderá ser utilizado por usuários que já tenham uma experiência na linguagem HTML, foi habilitada a opção para o usuário visualizar e editar o relatório também a partir do código (Figura 31). Após definir como será o relatório, o usuário poderá finalmente criá-lo, um exemplo de relatório desenvolvido pelo sistema é apresentado na Figura 32, logo abaixo.

61 61 Figura 32: Relatório exibido ao usuário. No exemplo da Figura 32, existe um relatório onde o usuário definiu que gostaria de consultar os produtos existentes no supermercado e seus respectivos códigos e valores. Para exibição do relatório, o usuário adicionou ao cabeçalho a imagem do supermercado e no rodapé colocou a data e a hora de geração do relatório. Na seção de detalhes o usuário preferiu criar uma tabela separando os campos da consulta e coloriu cada campo com uma cor diferente. Ao usuário, que teve apenas o trabalho de clicar em um botão para que o relatório já fosse exibido, parece simples, mas para que isso ocorresse, a aplicação executou os seguintes passos: 1 A partir do conteúdo das seções (cabeçalho, detalhes e rodapé) e da consulta gerados pelo usuário, é montado um documento XML obedecendo a estrutura definida no XML Schema; 2 A partir desse documento XML, a consulta é executada e o relatório vai sendo gerado em código HTML;