MyDesk: Uma Solução para Consumir Informações em Tempo...

1

MyDesk: Uma Solução para Consumir Informações em

Tempo Real de Sistemas Gerenciadores de Banco de Dados.

Eric Dos Santos Serafim, Rodrigo Prestes Machado

Curso de Análise e Desenvolvimento de Sistemas Faculdade de Tecnologia Senac RS (FATEC/RS)

Porto Alegre – RS – Brasil

[email protected], [email protected]

Abstract.

This article describes an alternative to consume information disregarding the

System Manager Database. It also describes some issues that motivated the

development of this work, such as the difficulties of organizations to integrate

their data in order to assist in decision making.

Resumo.

Este artigo descreve uma alternativa para consumir informações abstraindo o

Sistema Gerenciador de Banco de Dados. Descreve-se também, alguns aspectos

que motivaram a elaboração deste trabalho, tais como, as dificuldades das

organizações em integrar seus dados de forma a auxiliarem na tomada de

decisão.

1. Introdução

Segundo DealMaker (DealMaker, 2008), os pacotes de softwares surgiram na década de 60, e posteriormente os módulos integrados, que articulavam diversos módulos departamentais entre si. Os ERPs (Enterprise Resource Planning) (Consulting, 2008) surgiram a partir de uma evolução dos módulos integrados, que ganharam recursos de modelagem de processos.

Algumas empresas sentiram a necessidade de pacotes específicos para gerenciar suas relações com clientes e suas cadeias de suprimentos. Surgiram os aplicativos CRM (Customer relationship management) (Digital, 2008) e SCM (Supply Chain Management) (Chain, 2007) para suprir essas necessidades. Paralelamente apareceram também os servidores de Intranet (Russo, 2006), Extranet (MMCafe, 2005) e Internet (CGI.br, 2009). Sem falar do e-mail e das ferramentas de produtividade pessoal e colaboração. É natural que, em virtude destas ilhas de softwares isolados, as empresas tenham dificuldades em integrar seus negócios.

Felix Racca (CHAVES & FALSARELLA, 1995) afirma que haveria um problema na abordagem supracitada, pois o número de possibilidades de troca de dados aumenta de maneira rápida à medida que o número de aplicativos independentes cresce. Para facilitar a troca de dados entre um aplicativo e outro, surgiram os pacotes EAI

2

(Enterprise Application Integration) (Kioskea, 1998), que ainda assim não atendiam necessariamente todos os casos e era motivo de mais customizações.

Segundo Nolan (Nolan, 1977), são 5 (cinco) os estágios da Tecnologia da Informação nas organizações, o primeiro é o estágio de iniciação, neste estágio é onde ocorre a proliferação de aplicações, o planejamento inexiste e não há participação dos usuários no processo de levantamento das necessidades. Considerando este primeiro estágio, fica claro entendermos a origem das dificuldades que as organizações enfrentam em gerenciar seus dados, pois conforme estas organizações evoluem, as dificuldades aumentam proporcionalmente ao número de aplicações que utilizam, a integração torna-se um desafio. Em entrevista concedida para este artigo, Ricardo Kurtz (Kurtz, 2009), Ex-Presidente Nacional da ASSESPRO (ASSESPRO, 2009), diz que este quadro é presente nas organizações atuais, na maioria dos casos os diretores destas organizações não fazem idéia de como são gerados os relatórios ou planilhas que recebem de seus colaboradores, e qual foi o esforço deste colaborador para consolidar as informações e apresentá-las de forma que possa auxiliar na tomada de decisão.

Ricardo Kurtz também citou algumas dificuldades das organizações na utilização de sistemas de informação. Ele mencionou que um dos problemas mais relevantes neste caso, seria ter um sistema de gestão que faça todos os setores da empresa convergir para a organização (mesmo que utilizem recursos de outros sistemas). Aliado a isso um fornecedor que dê suporte qualificado e mantenha o sistema atualizado tecnológica, fiscal e administrativamente, além de acompanhar a evolução das necessidades da empresa ao longo do tempo.

Mediante a esse nível de dados disponíveis, as empresas acabam utilizam ferramentas alternativas para gerar informações relevantes para tomada de decisão. Neste caso podemos citar as planilhas eletrônicas, onde é possível importar dados de fontes distintas, gerar gráficos e relatórios. Como ponto negativo desta ferramenta, podemos citar a atualização das informações, pois o processo de importação deverá ser executado toda vez que surgir a necessidade de utilizar tais dados atualizados.

Outra abordagem seria a utilização de ferramentas de consolidação de dados, onde as informações relevantes são unidas em uma nova estrutura capaz de gerar dados úteis para a tomada de decisão. Mas neste caso, não temos as informações em tempo real, ou seja, até que o processo de consolidação seja executado, os dados disponíveis continuam desatualizados.

Este artigo tem como objetivo o desenvolvimento do MyDesk. Um sistema simplificado, para visualização de informações em tempo real, oriundas de qualquer banco de dados MySql (MySql, 2009). Desta forma, o usuário poderá configurar as informações que julga relevante para auxiliá-lo na tomada de decisão.

O presente artigo está organizado em 5 seções. A seção 2 apresenta os trabalhos relacionados com o tema, mostrando as possíveis soluções para o problema exposto. Na seção 3 descreve-se a solução do problema, juntamente com as funcionalidades do MyDesk. Na seção 4 estão descritos os métodos de validação do software. As conclusões e os trabalhos futuros estão expostos na seção 5.

3

2. Trabalhos Relacionados Nesta seção são descritas algumas soluções encontradas para visualizar informações de forma centralizada.

2.1. Pytagor

O Pytagor (Pytagor, 2009) é uma solução capaz de manter uma estrutura parecida com um desktop, mas seu principal objetivo é servir de repositório de arquivos na internet. Na verdade pode-se dizer que o Pytagor é um disco virtual.

Seu objetivo é manter todos os documentos que o usuário necessita, publicados em um ambiente na Internet, pois assim o usuário poderá baixar os documentos, alterar e reenviar para o Pytagor, de qualquer lugar que tenha acesso a Internet.

A proposta do Pytagor é interessante para usuários domésticos, que não tenham a necessidade de consumir informações de diversos sistemas ao mesmo tempo, isto é, usuários que estão fora do universo empresarial.

2.2. Google Web Desktop

O GWD (Google Web Desktop) (FlexDev, 2009) é um projeto que tem como principal objetivo unir todos os serviços da Google (Google, 2009), em uma interface web, onde o usuário possa realizar tarefas diárias como ler seu Google Mail, analisar documentos no Google Spread Sheets, olhar fotos no Google Web Picasa, usar o Google Talk e outros, apenas acessando uma vez com o seu usuário e senha cadastrados na Google.

A proposta do GWD é interessante, porém seu universo de atuação é restrito a uma única empresa, sem a possibilidade de o usuário utilizar a ferramenta para consumir informações de fonte de dados que este tenha acesso. Além disso, este projeto encontra-se em fase de protótipo.

2.3 Desktop Two

O Desktop Two (Two, 2009) é um serviço com aplicativos que busca trazer uma experiência semelhante à usabilidade que temos nos softwares para desktop.

Como o próprio nome sugere, trata-se de seu segundo desktop e o sistema tem a pretensão de substituir o primeiro. Uma atração é a agenda de contatos, mas também trabalha na linha da mídia com um MP3 (Moving Picture Experts Group) (Wester, 2008) e leitor de RSS (Really Simple Syndication) (Wester, 2007).

O sistema conta com aplicações úteis para quem deseja criar conteúdo para a Internet. Há um utilitário para blogs que ajuda o usuário a criar páginas simples por meio de uma interface visual, sem precisar trabalhar com HTML (Hypertext Markup Language) (ScriptBrasil, 2007) ou outros aspectos de programação.

Os aplicativos do OpenOffice (OpenOffice, 2009) ficam acessíveis diretamente a partir da interface web, de modo que podem ser criadas planilhas, documentos de texto e apresentações a partir de qualquer computador com facilidade.

4

A proposta do Desktop Two é simular um sistema operacional, com isso o que usuário tem na mão á flexibilidade de ter seu computador disponível em qualquer lugar que tenha acesso a Internet.

2.4 Excel

O Microsoft Excel (Excel, 2009) é um software capaz de importar dados de diversas fontes, tais como, arquivos XML, arquivos textos e de alguns banco de dados, utilizando o recurso de ODBC (Open Data Base Connectivity) (ODBC, 2009).

Nesta ferramenta é possível gerar gráficos e utilizar o recurso de lista de dados para visualizar as informações desejadas. Trata-se de uma ferramenta com recursos satisfatórios. Como pontos negativos, podemos mencionar a execução de tarefas repetitivas para importar os dados, também temos o problema de redundância de informação, sem falar que os dados permanecem desatualizados até que o processo de importação seja executado.

3. Implementação do MyDesk

Como foi exposto anteriormente, o objetivo deste estudo é construir o MyDesk, um sistema para visualização de informações oriundas de bancos de dados MySql. As tecnologias que mais se adaptaram para a proposta foram, Java (Sun, 2009) e Adobe Flex (Adobe, 2009). A linguagem Java foi utilizada para o desenvolvimento do WS (Web Service) (W3C_WSDL, 2009), responsável por extrair as informações do banco de dados, já a linguagem Flex foi utilizada para o desenvolvimento da interface do projeto. Ambas as linguagens utilizam máquina virtual para o seu funcionamento, com isso o projeto ganha em flexibilidade e portabilidade.

O MyDesk utiliza janelas para visualização das informações. As janelas operam de forma independente, ou seja, para cada janela o usuário configura: o banco, a tabela e os campos, de onde as informações serão extraídas. O MyDesk disponibiliza 5 tipos de filtros (Maior, Menor, Igual e Diferente) para serem aplicados nos campos selecionados, ou seja, ao selecionar um campo o usuário pode indicar qual filtro deseja aplicar juntamente com o dado a ser comparado. Exemplo: Campo A Maior que 10, Campo B Menor que 10, etc.

É possível indicar também, o tempo de sincronização dos dados e o título da janela, para uma melhor identificação. Na Figura 1 apresenta-se a janela do sistema.

Figura 1. Janela do sistema.

5

O sistema permite a configuração de diversas janelas, sem limite por usuário. Em cada janela o usuário tem duas opções para visualização dos dados. Em forma de lista, o sistema apresenta os dados um abaixo do outro, com aspecto de uma planilha eletrônica. A outra opção é gráfica, neste caso o usuário poderá escolher entre três tipos de gráficos (Pizza, Barras, Colunas).

Na Figura 2 demonstra-se o processo de configuração da janela. Neste caso o usuário acessa o MyDesk, aciona a opção de configurar janelas, após determina de onde as informações serão extraídas.

Figura 2. Configuração das janelas.

A Figura 3 demonstra o fluxo de execução entre a interface do MyDesk e o WS, responsável por extrair os dados dos SGBDs (Sistema Gerenciador de Banco de Dados).

Figura 3. Fluxo de Execução

De forma descritiva apresentamconfiguração de cada janela o MyDesk invoca o comunicação (Figura 4), este por sua vez conectainterface, após o WS buscaarquivo de retorno, contendo todos os registros extraídos do banco de dadoso WS envia o arquivo XMLcontendo os dados, para a interface do MyDesk, queconfiguração definida pelo usuário.definido pelo usuário na própria

Figura 4.

Figura 5. Arquivo XML de retorno.

apresentam-se as ações executadas na Figura configuração de cada janela o MyDesk invoca o WS, enviando o arquivo de

este por sua vez conecta ao banco de dados especificadoo WS busca os dados da tabela especificada. Em seguida o WS

arquivo de retorno, contendo todos os registros extraídos do banco de dadosarquivo XML (Extensible Markup Language) (W3C, 2009)

para a interface do MyDesk, que os apresenta na janela,configuração definida pelo usuário. Este processo se repetirá a cada ciclo de tempo

na própria janela.

Figura 4. Arquivo XML de comunicação com WS.

Figura 5. Arquivo XML de retorno.

6

as ações executadas na Figura 3. Em base à , enviando o arquivo de

ao banco de dados especificado na m seguida o WS monta o

arquivo de retorno, contendo todos os registros extraídos do banco de dados. Logo após (W3C, 2009) (Figura 5) na janela, conforme a

Este processo se repetirá a cada ciclo de tempo,

7

3.1. Estrutura e Modelagem

A modelagem foi dividida em dois grupos, conforme Figura 6. O grupo Interface e o grupo Web Service.

Figura 6. Estrutura da Modelagem

O MyDesk utiliza o Flash Player (Adobe, 2009) para executar sua interface, esta estrutura segue o mesmo princípio que uma JVM (Java Virtual Machine) (Sun, 2009), só que voltada para arquivos SWF (Small Web File) (Adobe, 2009). O módulo responsável por consumir informações do SGBD foi desenvolvido em forma de serviço. O WS foi desenvolvido em Java, utilizando Axis (WSApache, 2009) sobre Apache TomCat (Apache, 2009).

A interface foi modelada utilizando o padrão MVC (Model View Controller) (Sun_MVC, 2009) e DAO (Data Access Object) (Sun_DAO, 2009). O SGBD utilizado para armazenar os dados necessários para a interface foi o MySql. Caso haja a necessidade de utilizar outro SGBD, bastará desenvolver a fábrica deste, que o projeto estará apto para operar com o novo SGBD escolhido. Na Figura 7 demonstra-se a estrutura da interface.

Figura 7. Camadas da Interface

A linguagem utilizada para desenvolver a interface foi o Adobe Flex. Esta linguagem utiliza o AS3 (Action Script 3) (Adobe, 2009) para toda parte lógica do sistema, e o MXML (Magic Extensible Markup Language) (Adobe, 2009) para construção dos objetos que serão apresentados ao usuário. O resultado final de um projeto desenvolvido

8

em Adobe Flex, é um arquivo com extensão SWF, este arquivo utiliza o Flash Player para ser executado.

Já o WS foi desenvolvido utilizando o padrão DAO. Atualmente o WS consome dados oriundos do SGBD MySql, mas futuramente será desenvolvido o acesso a outros SGBDs, conforme a evolução do projeto. Neste caso bastará desenvolver a camada de comunicação com SGBD desejado.

A linguagem utilizada para desenvolver o WS foi o Java, utilizando Axis sobre Apache TomCat. Na Figura 8 demonstra-se a estrutura do WS.

Figura 8. Camadas do WS

4. Validações

Para validar a solução proposta neste trabalho, foi realizado um estudo de caso, onde a necessidade de um usuário em consumir informações de fonte de dados diferentes em tempo real (conforme tempo de sincronização definido), é demonstrada.

4.1. Cenário do Estudo de Caso

Para tornar possível a validação do MyDesk, foi criado um cenário onde dois usuários possuem algumas aplicações com fontes de dados distintas. Neste cenário, os usuários precisam consumir informações dos seus sistemas (vendas e compras) em tempo real. Quando uma venda ou uma compra ocorre, o usuário necessita visualizar esta informação, sem a necessidade de efetuar importações de dados, gerar relatórios, etc.

4.2. Execução do Estudo de Caso

A validação foi a configuração de duas janelas por usuário, onde cada usuário acessou o sistema em computadores distintos, e configurou ambas as janelas da seguinte forma:

• Na primeira janela os usuários configuraram o acesso as informações de vendas, onde o tempo de sincronização desta janela foi definido em 10 segundos. Nesta janela definiu-se a opção de visualização “Lista”.

• Na segunda janela os usuários configuraram o acesso as informações de compras, onde o tempo de sincronização desta janela foi definido em 20 segundos. Nesta janela definiu-se a opção de visualização, “Gráfico Pizza”.

9

Este teste cobriu as funções de configuração de diversas janelas, para bancos distintos ou iguais. Neste ponto questionou-se a opinião dos usuários, com relação a usabilidade no momento da configuração. Ambos os usuários disseram que não encontraram dificuldades para configurar o acesso as informações desejadas, e que o sistema de passo a passo adotado, facilita no processo de configuração.

Após as configurações das janelas, iniciou-se a etapa de manipulação dos dados (inserção, alteração e exclusão) de ambos os sistemas (vendas e compras). Neste teste foram realizadas as validações de eficiência, negação de serviço e funcionalidades de controle de concorrência dos dados. Os resultados foram apresentados conforme o previsto, as janelas sincronizaram os dados conforme suas configurações de tempo, o sistema apresentou os dados de acordo com a opção de visualização da janela.

É importante salientar que neste teste não foi prevista a escalabilidade do projeto, isto é, mais de 1000 usuários conectados, com 30 janelas configuradas, sincronizando a cada 20 segundos.

Como forma de verificar a tolerância a falhas do sistema, foi executado um segundo teste:

• Incluiu-se um campo na tabela de vendas, chamado “Teste”. • Configurou-se uma terceira janela, consumindo as informações da tabela de

vendas e do campo “Teste”. • Excluiu-se o campo “Teste” da tabela de vendas.

Neste teste foi comprovado que o MyDesk possui tolerância a falhas, pois o sistema não apresentou nenhum problema de travamento por causa da ausência da coluna “Teste”. O MyDesk apresentou ao invés dos dados, uma mensagem informando que a coluna especificada na configuração, não existia na tabela informada. Após a coluna ter sido incluída novamente, o MyDesk apresentou os dados sem nenhum aviso adicional. No caso do banco ou da tabela não existir, o resultado apresentado foi o mesmo.

5. Conclusões e Trabalhos Futuros

Neste trabalho avaliamos uma alternativa para consumir informações em tempo real de sistemas que utilizam banco de dados MySql. A utilização da linguagem Java para desenvolver o Web Service mostrou-se eficiente e segura, juntamente com a linguagem Adobe Flex para o desenvolvimento da Interface, que proporcionou flexibilidade na apresentação dos dados. Esta linguagem também facilitou o acesso de forma nativa ao Web Service desenvolvido.

As funcionalidades apresentadas pelo MyDesk foram capazes de atender as necessidades de usuários com foco empresarial de forma simples e objetiva. Quando foi necessário modificar a estrutura do banco de dados do sistema que fornecia as informações, ou até mesmo indispor o banco de dados, o MyDesk comportou-se de forma satisfatória, sem maiores problemas para o usuário.

Alguns pontos de melhorias, que podem ser acrescentados em trabalhos futuros, foram constatados durante este trabalho, tais como:

10

• Efetuar importação da estrutura do banco de dados do usuário (engenharia reversa). Esta funcionalidade facilitará o processo de cadastramento das fontes de dados que o usuário utilizará para consumir as informações desejadas.

• Desenvolver funcionalidade capaz de consumir dados em mais de uma tabela ao mesmo tempo, ou seja, em uma única janela o usuário define quantas tabelas julgar necessário, após o sistema une (junção) estas tabelas para buscar as informações.

• Desenvolver funcionalidade capaz de consumir dados de bancos de dados diferentes, mas que possuam a mesma estrutura, em uma única janela. Neste caso seria uma junção entre bancos.

• Utilizar cláusulas SQL (Structured Query Language) (ANSI, 2009) de agrupamento de dados, como por exemplo, SUM, AVG, MAX, MIN e COUNT. A funcionalidade irá agregar valor a funcionalidades supracitadas.

• Utilizar Hibernate (Hibernate, 2009) para tradução do comando SQL. Atualmente utiliza-se uma classe própria para executar esta tarefa.

• Disponibilizar outros tipos de gráficos, proporcionando ao usuário uma gama maior de opções para visualização dos dados.

• Desenvolver funcionalidade de ajuste de tamanho das janelas, juntamente com as opções de maximizar e minimizar.

• Desenvolver recurso de restauração das janelas fechadas (não excluídas) pelo usuário. Assim se o usuário fechou uma determinada janela, mas posteriormente deseja visualizá-la novamente, bastará acionar esta opção, pois atualmente ao fechar uma janela o usuário é questionado se deseja excluí-la, caso o usuário opte por “não”, o sistema somente fecha a janela, que será exibida novamente no próximo acesso do usuário ao sistema.

6. Referências Bibliográficas

Adobe. (2009). Flex. Acesso em 03 de 05 de 2009, disponível em http://www.adobe.com/products/flex

ANSI. (2009). SQL. Acesso em 02 de 06 de 2009, disponível em http://www.ansi.org

Apache. (2009). Apache. Acesso em 04 de 05 de 2009, disponível em http://www.apache.org/

ASSESPRO. (2009). http://www.assespro.com.br.

CadCobol. (1998). História do COBOL. Acesso em 15 de 03 de 2009, disponível em http://www.cadcobol.com/histor_1.htm

CGI.br. (2009). Internet. Acesso em 05 de 04 de 2009, disponível em http://www.cgi.br/regulamentacao/resolucoes.htm

Chain, S. (2007). SCM. Acesso em 05 de 04 de 2009, disponível em http://www.supplychainonline.com.br

CHAVES, E. O., & FALSARELLA, O. M. (1995). Os sistemas de informação e sistemas de apoio à decisão. In: Revista do Instituto de Informática (pp. v. 3, n.1, p. 24-31).

Consulting, C. (2008). Conceitos sobre ERP. Acesso em 18 de 03 de 2009, disponível em http://www.cbsconsulting.com.br/erp.htm

11

Cunha, D. (2002). Web Services, SOAP e Aplicações Web. Intelinet.

DealMaker. (2008). Os Super Serviços. Acesso em 15 de 03 de 2009, disponível em http://www.dealmaker.com.br

Deitel. (2005). Java - Como Programar - 6ª Edição. Pearson Education.

Digital, L. (2008). CRM. Acesso em 20 de 03 de 2009, disponível em http://www.logicadigital.com.br/desenv_softwares_crm.asp

FlexDev. (2009). http://www.flexdev.com.br/gwd/main.html. Google Web Desktop .

Fortran. (1997). História FORTRAN. Acesso em 18 de 03 de 2009, disponível em http://www.fortran.com

Google. (2009). http://www.google.com.br.

Hibernate. (2009). Hibernate. Acesso em 10 de 06 de 2009, disponível em https://www.hibernate.org

Jr, P. J. (2007). Java Guia do Programador. Novatec.

Kioskea. (1998). EAI. Acesso em 10 de 04 de 2009, disponível em http://pt.kioskea.net/contents/entreprise/eai.php3

Kurtz, R. (20 de 05 de 2009). ERP. (E. Serafim, Entrevistador)

Lins, J. A. (2006). Web Services em Java. Brasport.

Manzi, F. (2007). Flash CS3 Professional. Criando Além da Animação. Erica.

Mengue, F. (2007). Curso de Java Básico. Unicamp.

Excel, M. (2009). Excel. Acesso em 07 de 07 de 2009, disponível em http://office.microsoft.com/pt-br/excel/default.aspx

MMCafe. (2005). Extranet. Acesso em 05 de 04 de 2009, disponível em http://www.mmcafe.com.br/solucoes/administracaogestao/extranet/beneficiosdaextranetadministracaogestao

MySql. (2009). http://www.mysql.com.

Nolan. (1977). Information Systems. New York: HTE.

ODBC. (2009). ODBC. Acesso em 07 de 07 de 2009, disponível em http://support.microsoft.com/kb/110093

OpenOffice. (2009). OpenOffice. Acesso em 12 de 05 de 2009, disponível em http://www.broffice.org/

Pytagor. (2009). http://www.pytagor.com.

Ramalho, C. J. (2005). Web Services - Aplicações Distribuídas sobre Protocolos Internet. FCA.

Russo, B. (2006). O que é a Intranet. Acesso em 05 de 04 de 2009, disponível em http://www.brunorusso.eti.br/documentacao/O_que_e_a_Intranet.pdf

Santos, M. (2008). Adobe Flex A Partir do Zero. Desde a instalção à produção avançada. MsDev Studio.

Schimitz, D. P. (2008). Adobe Flex Builder 3.0 - Conceitos E Exemplos. Brasport.

12

ScriptBrasil. (2007). HTML. Acesso em 02 de 05 de 2009, disponível em http://www.scriptbrasil.com.br/forum/index.php?showtopic=99281

Sun. (2009). Java. Acesso em 03 de 05 de 2009, disponível em http://www.sun.com

Sun_DAO. (2009). DAO. Acesso em 05 de 06 de 2009, disponível em http://java.sun.com/blueprints/patterns/DAO.html

Sun_MVC. (2009). MVC. Acesso em 05 de 06 de 2009, disponível em http://java.sun.com/blueprints/patterns/MVC.html

Tong, K. K. (2008). Axis2 book: Developing Web Services with Apache Axis2 (2nd Edition). TipTec Development.

Two, D. (2009). http://www.desktoptwo.com.

W3C. (2009). XML. Acesso em 02 de 06 de 2009, disponível em http://www.w3.org/XML

W3C_WSDL. (2009). WSDL. Acesso em 06 de 06 de 2009, disponível em http://www.w3.org/TR/wsdl

Wester, I. (2008). MP3. Acesso em 02 de 05 de 2009, disponível em http://www.infowester.com/histomptres.php

Wester, I. (2007). RSS. Acesso em 02 de 05 de 2009, disponível em http://www.infowester.com/rss.php

William Sanders, C. C. (2007). ActionScript 3.0 Design Patterns: Object Oriented Programming Techniques (Adobe Developer Library). O'Reilly Bookstore.

WSApache. (2009). Axis. Acesso em 03 de 05 de 2009, disponível em http://ws.apache.org/axis/java/user-guide.html#WhatIsAxis

13

Anexos

Eric Dos Santos Serafim, Rodrigo Prestes Machado

Curso de Análise e Desenvolvimento de Sistemas Faculdade de Tecnologia Senac RS (FATEC/RS)

Porto Alegre – RS – Brasil

[email protected], [email protected]

14

Sumário

Requisitos 15

Requisitos Diretos 15

Requisitos Indiretos 15

Modelagem 15

Modelagem Web Service 15

Diagrama de Casos de Uso 15

Casos de Uso 16

Casos de Uso Expandidos 16

Consumir Fonte de Dados (CSU01) 16

Diagrama de Classes 17

Diagrama de Casos de Uso 18

Casos de Uso 19

Casos de Uso Expandidos 19

Autenticar Usuário (CSU01) 19

Cadastrar Usuário (CSU02) 19

Alterar Usuário (CSU03) 20

Cadastrar Fonte de Dados (CSU04) 20

Cadastrar Janela (CSU05) 21

Alterar Janela (CSU06) 22

Excluir Janela (CSU07) 22

Banco de Dados 24

Diagrama Entidade Relacionamento 24

15

Requisitos

Requisitos Diretos

1. Cadastro de Usuários.

2. Consumir informações de banco de dados (Mysql) via Web Service.

3. Configurar/Salvar perfil do usuário (Janelas de visualização de informações).

4. Controlar acesso de usuários.

5. Visualizar informações de banco de dados diferentes em um único ambiente.

Requisitos Indiretos

1. Consumir qualquer informação do SGDB (Mysql).

Modelagem

A modelagem foi dividida em dois grupos, conforme Figura 9. O grupo Interface e o grupo Web Service.

Figura 9. Estrutura da Modelagem

Modelagem Web Service

Diagrama de Casos de Uso

Na Figura 10, apresenta-se o diagrama de casos de uso do WS.

Figura 10. Diagrama de Casos de Uso

16

Casos de Uso

1. Consumir Fonte de Dados

Casos de Uso Expandidos

Consumir Fonte de Dados (CSU01)

Sumário: A interface utiliza o caso de uso para consumir informações de diversas fontes de dados.

Ator Primário: Interface.

Pré-condições: A fonte de dados deverá estar acessível.

Cenário Principal:

1. A Interface envia o local e o nome da fonte de dados, nome da tabela, nome das colunas da tabela, juntamente com os filtros que serão aplicados na consulta.

2. O sistema cria o XML e valida seu formato.

3. O sistema abre a fonte de dados e executa a consulta.

4. O sistema monta o arquivo XML de retorno, contendo, nome das colunas, label das colunas e o conteúdo das colunas.

5. O sistema envia o XML para a Interface e o caso de uso termina.

Cenário Alternativo:

O nome da fonte de dados, da tabela e as colunas devem existir, isto é, tem de estarem corretos.

Cenário de Exceção:

Caso o cenário alternativo não seja atendido, o sistema enviará um XML vazio.

17

Diagrama de Classes

Na Figura 11, apresenta-se a diagrama de classes do WS.

Figura 11. Diagrama de Classes WS

18

Modelagem Interface

Diagrama de Casos de Uso

Na Figura 12, apresenta-se o diagrama de casos de uso da Interface.

Figura 12. Diagrama de Casos de Uso da Interface

19

Casos de Uso

1. Autenticar Usuário

2. Cadastrar Usuário

3. Alterar Usuário

4. Cadastrar Fonte de Dados

5. Cadastrar Janela

6. Alterar Janela

7. Excluir Janela

Casos de Uso Expandidos

Autenticar Usuário (CSU01)

Sumário: O usuário utiliza o caso de uso para identificar-se no sistema.

Ator Primário: Usuário.

Pré-condições: O usuário deve estar cadastrado no sistema.

Cenário Principal:

1. O usuário aciona a opção de acessar o sistema.

2. O sistema solicita o email e senha.

3. O usuário informa os dados.

4. O sistema confere os dados e exibe a tela inicial.

Cenário de Exceção

Caso o usuário não seja identificado pelo sistema, este não terá acesso às funcionalidades disponíveis.

Cadastrar Usuário (CSU02)

Sumário: O administrador utiliza o caso de uso para cadastrar os usuários que terão acesso ao sistema.

Ator Primário: Administrador.

Precondições: O administrador está autenticado pelo sistema.

Cenário Principal:

1. O administrador solicita a opção de cadastrar usuário

2. O sistema solicita o nome, a forma de tratamento (Sr(A) ou Prezado(a)), email, nível (Usuário ou Administrador), senha e re-senha.

3. O administrador informa os dados.

4. O administrador confirma a inclusão.

5. O sistema grava as informações e o caso de uso termina.

20


É obrigatório o preenchimento dos campos email, senha e re-senha.

O email deve ser válido, pois será o autenticador (login) do usuário.


Caso o usuário informe a re-senha diferente da senha, o sistema não permitirá a inclusão do registro.

Caso o email informado já exista no cadastro do sistema, ou NÃO seja um email válido, o sistema não permitirá a inclusão do registro.

Alterar Usuário (CSU03)

Sumário: O usuário utiliza o caso de uso para modificar seus dados cadastrais no sistema.


Pré-condições: O usuário está autenticado pelo sistema.

Cenário Principal:

1. O usuário solicita a opção de alterar cadastro de usuários.

2. O sistema solicita o nome, a forma de tratamento (Sr(A) ou Prezado(a)), email, nível (Usuário ou Administrador), senha e re-senha.


4. O usuário confirma a modificação.



É obrigatório o preenchimento dos campos email, senha e re-senha.

O email deve ser válido, pois será o autenticador (login) do usuário.


Caso o usuário informe a re-senha diferente da senha, o sistema não permitirá a alteração do registro.

Caso o email informado já exista no cadastro do sistema, ou NÃO seja um email válido, o sistema não permitirá a alteração do registro.

Cadastrar Fonte de Dados (CSU04)

Sumário: O usuário utiliza o caso de uso para cadastrar a fonte de dados que irá utilizar para visualizar informações no sistema.



Cenário Principal:

1. O usuário solicita a opção de cadastrar fonte de dados.

21

2. O sistema solicita o nome da fonte de dados, o driver (Mysql, Firebird, etc), o caminho da fonte de dados, a porta utilizada pela fonte de dados, o usuário e a senha de acesso.


4. O sistema solicita o nome da tabela, o nome dos campos, o tipo e tamanho de cada campo.


6. O usuário confirma a inclusão.



É obrigatório o preenchimento de todos os campos.


Caso o usuário informe algum campo incorretamente, NÃO será possível consumir informações desta fonte de dados.

Cadastrar Janela (CSU05)

Sumário: O usuário utiliza o caso de uso para cadastrar a janela que irá utilizar para visualizar informações no sistema.



Cenário Principal:

1. O usuário solicita a opção de cadastrar janela.

2. O sistema solicita o título e o tempo de sincronização (este dado servirá para o sistema saber em quanto tempo deverá atualizar as informações da janela).


4. O sistema lista as fontes de dados cadastradas, juntamente com as tabelas e seus respectivos campos.

5. O usuário seleciona a fonte de dados, a tabela, os campos e informa o filtro que será aplicado em cada campo.

6. O sistema solicita a forma de visualização dos dados (lista ou gráfico).

7. O usuário seleciona a opção desejada e confirma a inclusão.



Caso o usuário não informe o tempo de sincronização (tempo = 0), o sistema assumirá que esta janela NÃO atualizará as informações em tempo real.

22

Alterar Janela (CSU06)

Sumário: O usuário utiliza o caso de uso para modificar a janela que irá utilizar para visualizar informações no sistema.



Cenário Principal:

1. O usuário solicita a opção de alterar janela.

2. O sistema solicita o usuário, o título e o tempo de sincronização (este dado servirá para o sistema saber em quanto tempo deverá atualizar as informações da janela).


4. O sistema solicita a forma de visualização dos dados (lista ou gráfico).

5. O usuário seleciona a opção desejada e confirma a alteração.



Caso o usuário não informe o tempo de sincronização (tempo = 0), o sistema assumirá que esta janela NÃO atualizará as informações.

Excluir Janela (CSU07)

Sumário: O usuário utiliza o caso de uso para excluir a janela de visualização de informações do sistema.



Cenário Principal:

1. O usuário seleciona a janela desejada para exclusão.

2. O usuário aciona a opção de excluir janela e o caso de uso termina.

23

Diagrama de Classes

Na Figura 13, apresenta-se o diagrama de classes da Interface.

Figura 13. Diagrama de Classes da Interface.

24

Banco de Dados

Diagrama Entidade Relacionamento

Na Figura 14, apresenta-se o diagrama de entidade e relacionamento da Interface.

Figura 14. Diagrama de Entidade e Relacionamento

25

Dicionário de Dados

Entidade 'aparencia'

Atributo Descrição

CODUSUARIO Código sequencial desta entidade.

NOMESKIN Neste campo guarda-se o nome do skin definido pelo usuário.

Entidade 'banco'


CODBANCO Código sequencial desta entidade.

NOME Nome do banco.

DRIVER Driver do banco: 1: MySql

LOCAL Local onde encontra-se o banco de dados.

PORTA Porta para acesso ao banco de dados.

LOGIN Usuário para acesso ao banco de dados.

SENHA Senha para acesso ao banco de dados.

Entidade 'campo'


CODTABELA Código da tabela que detém o campo.

CODCAMPO Código sequencial desta entidade.

NOME Nome do campo.

TIPO Tipo do campo.

Date, String, Integer, Numeric, Boolean, Blob

TAMANHO Tamanho do campo.

APRESENTACAO Nome de apresentação do campo.

Entidade 'config_filtro'


CODJANELA Código sequencial desta entidade.

CODTABELA Código da tabela selecionada.

CODCAMPO Código do campo selecionado.

FILTRO Filtro definido para ser aplicado no campo selecionado.

OPERACAO Operação para ser aplicada no filtro informado.

Maior, Menor, Diferente, Igual

Entidade 'configuração'



TEMPO_SINCRONIZA Tempo em segundos que a janela irá sincronizar os dados

TIPO_GRAFICO Tipo do gráfico definido pelo usuário: -1: Indefinido 0: Barras 1: Colunas 2: Pizza

CAMPO_LEGENDA Nome do campo que foi definido para montar a legenda do gráfico

CAMPO_CONTEUDO Nome do campo que foi definido para montar o conteúdo do gráfico

26

Entidade 'janela'



CODUSUARIO Código do usuário que pertence a janela.

TITULO Título da janela

ESTADO Estado da janela: 0: Normal 1: Minimizada 2: Maximizada 3: Fechada

ALTURA Altura da janela.

LARGURA Largura da janela

POSX Posição do eixo X que a janela encontra-se

POSY Posição do eixo Y que a janela encontra-se

Entidade 'tabela'


CODTABELA

Código sequencial desta entidade.

CODBANCO Código do banco que a tabela pertence.

NOME Nome da tabela.

Entidade 'usuario'


CODUSUARIO Código sequencial desta entidade.

NOME Nome do usuário

TRATAMENTO Sr(A) ou Prezado(a)

EMAIL Email do usuário

SENHA Senha do usuário

NIVEL Nível do usuário: 0: Usuário 1: Administrador

MyDesk: Uma Solução para Consumir Informações em Tempo...

Documents

Transcript of MyDesk: Uma Solução para Consumir Informações em Tempo...